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Abstract 

This  paper  investigates  how  the  vision  of  the  Semantic  Web  can  be  carried  over  to  the 
realm  of  email.  We  introduce  a  general  notion  of  semantic  email,  in  which  an  email  mes¬ 
sage  consists  of  a  structured  query  or  update  coupled  with  corresponding  explanatory  text. 
Semantic  email  opens  the  door  to  a  wide  range  of  automated,  email-mediated  applications 
with  formally  guaranteed  properties.  In  particular,  this  paper  introduces  a  broad  class  of  se¬ 
mantic  email  processes.  For  example,  consider  the  process  of  sending  an  email  to  a  program 
committee,  asking  who  will  attend  the  PC  dinner,  automatically  collecting  the  responses, 
and  tallying  them  up.  We  define  both  logical  and  decision-theoretic  models  where  an  email 
process  is  modeled  as  a  set  of  updates  to  a  data  set  on  which  we  specify  goals  via  cer¬ 
tain  constraints  or  utilities.  We  then  describe  a  set  of  inference  problems  that  arise  while 
trying  to  satisfy  these  goals  and  analyze  their  computational  tractability.  In  particular,  we 
show  that  for  the  logical  model  it  is  possible  to  automatically  infer  which  email  responses 
arc  acceptable  w.r.t.  a  set  of  constraints  in  polynomial  time,  and  for  the  decision-theoretic 
model  it  is  possible  to  compute  the  optimal  message-handling  policy  in  polynomial  time. 
In  addition,  we  show  how  to  automatically  generate  explanations  for  a  process’s  actions, 
and  identify  cases  where  such  explanations  can  be  generated  in  polynomial  time.  Finally, 
we  discuss  our  publicly  available  implementation  of  semantic  email  and  outline  research 
challenges  in  this  realm. 1 
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1  Introduction 


The  Semantic  Web  envisions  a  portion  of  the  World-Wide  Web  (WWW)  in  which 
the  underlying  data  is  machine  understandable  and  can  thus  be  exploited  for  im¬ 
proved  querying,  aggregation,  and  interaction  [4].  However,  despite  the  great  po¬ 
tential  of  this  vision  and  numerous  efforts,  the  growth  of  the  Semantic  Web  has 
been  stymied  by  the  lack  of  incentive  to  create  content,  and  the  high  cost  of  doing 
so.  Content  owners  are  not  motivated  to  create  the  structured  representations  nec¬ 
essary  to  contribute  to  the  Semantic  Web  without  seeing  the  immediate  benefit  of 
their  significant  efforts.  In  fact,  this  problem  is  not  unique  to  the  Semantic  Web  — 
the  Database  and  Knowledge  Base  communities  have  long  recognized  that  users 
shy  away  from  their  tools  because  the  perceived  benefits  are  outweighed  by  the 
conceptual  difficulty  and  overhead  of  structuring  data.  Instead,  users  often  resort  to 
spreadsheets,  structured  files  or  just  plain  text.  Ironically,  in  many  cases  the  resul¬ 
tant  lack  of  data  management  facilities,  and  reasoning  capabilities,  ultimately  leads 
to  more  work  for  users  down  the  road. 

This  paper  explores  this  problem  by  identifying  a  pain  point  where  the  cost/benefit 
equation  associated  with  structuring  data  can  be  changed  dramatically.  While  the 
WWW  is  a  rich  information  space  in  which  we  spend  significant  amounts  of  time, 
many  of  us  spend  as  much  or  more  time  on  email.  With  the  exception  of  the  generic 
header  fields  associated  with  each  message,  email  messages  typically  do  not  have 
semantic  features.  While  the  majority  of  email  will  remain  this  way,  this  paper 
argues  that  adding  semantic  features  to  email  offers  opportunities  for  improved 
productivity  while  performing  some  very  common  tasks.  We  establish  the  theoret¬ 
ical  foundations  for  Semantic  Email  and  address  some  of  the  practical  challenges 
associated  with  it  via  a  completely  implemented  system. 

To  illustrate  the  promise  of  Semantic  Email,  consider  several  examples: 

•  Information  Dissemination:  In  the  simplest  case,  suppose  you  send  a  talk  an¬ 
nouncement  via  email.  With  suitable  semantics  attached  to  the  email,  sending 
the  announcement  can  also  result  in  automatically  (1)  posting  the  announce¬ 
ment  to  a  web  calendar,  and  (2)  sending  reminders  a  day  before  the  talk. 

•  Event  Planning:  Imagine  you  are  organizing  a  program  committee  meeting 
and  you  want  to  know  which  PC  members  will  stay  for  dinner  after  the  meet¬ 
ing.  Currently,  you  must  send  out  the  question  and  compile  the  replies  manu¬ 
ally,  leafing  through  emails  one  by  one.  With  semantic  email,  the  PC  mem¬ 
bers  can  provide  the  reply  in  a  way  that  can  be  automatically  interpreted  and 
compiled,  enabling  such  planning  to  scale  to  much  larger  numbers  of  people. 
In  addition,  after  a  few  days,  unresponsive  PC  members  can  be  automatically 
reminded  to  respond,  and  those  who  have  said  they’re  not  coming  to  the  PC 
meeting  need  not  be  bothered  with  this  query  at  all.  Alternatively,  suppose  that 
you  are  organizing  a  balanced  potluck,  where  people  should  bring  either  an 
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appetizer,  entree,  or  dessert,  and  you  want  to  ensure  that  the  meal  is  balanced. 
Here  semantic  email  can  help  ensure  that  the  potluck  is  indeed  balanced  by 
examining  the  replies  and  requesting  changes  where  necessary. 

•  Report  Generation:  Suppose  you  need  to  collect  projected  budget  numbers 
from  a  large  set  of  managers.  With  semantic  email,  you  could  send  a  single 
email  request  and  have  the  system  automatically  tabulate  the  responses,  possi¬ 
bly  requiring  the  values  to  satisfy  certain  individual  or  aggregate  constraints. 
The  system  could  then  easily  generate  a  spreadsheet  report  or  integrate  this 
data  with  other  sources  (e.g.,  prior  budgets). 

•  Auction/Giveaway:  Imagine  you  want  to  give  away  concert  tickets  that  you 
cannot  use.  You  would  like  to  send  out  an  announcement  and  have  the  semantic 
email  system  give  out  (or  auction)  the  tickets  to  the  first  respondents.  When  the 
tickets  are  gone,  the  system  should  respond  politely  to  later  requests. 

These  examples  are  of  course  illustrative  rather  than  exhaustive.  In  general,  there 
are  at  least  three  ways  in  which  semantics  can  be  used  to  streamline  aspects  of  our 
email  habitat: 

(1)  Update:  We  can  use  an  email  message  to  add  data  to  some  source  (e.g.,  a  web 
page,  as  in  our  first  example). 

(2)  Query:  Email  messages  can  be  used  to  query  other  users  for  information. 
Semantics  associated  with  such  queries  can  then  be  used  to  automatically  an¬ 
swer  common  questions  (e.g.,  seeking  my  phone  number  or  directions  to  my 
office). 

(3)  Process:  We  can  use  semantic  email  to  manage  simple  but  tedious  processes 
that  we  currently  handle  manually. 

Because  email  is  not  set  up  to  handle  these  tasks  effectively,  accomplishing  them 
by  hand  can  be  tedious,  time-consuming,  and  error-prone.  The  techniques  needed 
to  support  the  first  two  uses  of  semantic  email  depend  on  whether  the  message  is 
written  in  text  by  the  user  or  formally  generated  by  a  program  on  the  sender’s  end. 
In  the  user-generated  case,  we  would  need  sophisticated  methods  for  extracting  the 
precise  update  or  query  from  the  text  (e.g.,  [15,31]).  In  both  cases,  we  require  some 
methods  to  ensure  that  the  sender  and  receiver  share  terminologies  in  a  consistent 
fashion. 

This  paper  focuses  on  the  third  use  of  semantic  email  to  streamline  processes,  as 
we  believe  it  has  the  greatest  promise  for  increasing  productivity  and  is  where  users 
currently  feel  the  most  pain.  These  processes  support  the  common  case  of  asking 
people  a  set  of  questions,  collecting  their  responses,  and  ensuring  that  the  results 
satisfy  some  set  of  goals.  Some  hardcoded  email  processes,  such  as  the  meeting 
request  feature  in  Outlook,  invitation  management  via  Evite,  and  contact  manage¬ 
ment  via  GoodContacts,  have  made  it  into  popular  use.  Each  of  these  commercial 
applications  is  limited  in  its  scope,  but  validates  our  claim  about  user  pain.  Our  goal 
in  this  paper  is  to  sketch  a  general  infrastructure  for  semantic  email  processes,  and 
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to  analyze  the  inference  problems  it  needs  to  solve  to  manage  processes  effectively 
and  guarantee  their  outcome. 

Collaboration  systems  such  as  Lotus  Notes/Domino  and  Zaplets  offer  scripting  ca¬ 
pabilities  and  some  graphical  tools  that  could  be  used  to  implement  sophisticated 
email  processes.  However,  these  systems  (as  with  typical  workflow  systems  [44]) 
lack  support  for  reasoning  about  data  collected  from  a  number  of  participants  (e.g., 
as  required  to  balance  a  potluck  or  ensure  that  a  collected  budget  satisfies  aggre¬ 
gate  constraints).  In  addition,  such  processes  are  constructed  from  arbitrary  pieces 
of  code,  and  thus  lack  the  formal  properties  that  our  declarative  model  provides.  We 
describe  these  properties  and  the  limitations  of  existing  systems  in  more  detail  in 
Sections  3  and  5.  Finally,  messages  in  such  systems  lack  the  structured  content  (i.e., 
in  RDF  [32])  of  semantic  email,  precluding  automated  processing  by  the  recipient 
(e.g.,  to  decline  invitations  for  unavailable  times). 

Our  work  is  the  first  to  articulate  and  implement  a  general  model  of  semantic  email 
processes  (SEPs).  Our  technical  contributions  are  the  following.  Section  2  intro¬ 
duces  a  formalization  for  semantic  email  processes.  The  formalization  specifies  the 
meaning  of  semantic  email  processes  and  exposes  several  fundamental  reasoning 
problems  that  can  be  used  by  the  semantic  email  manager  to  facilitate  SEP  creation 
and  execution.  In  particular,  a  key  challenge  is  to  decide  when  and  how  the  manager 
should  direct  the  process  toward  an  outcome  that  meets  the  originator’s  goals.  We 
address  this  challenge  with  two  different  formal  models.  First,  Section  3  addresses 
this  challenge  by  describing  a  model  of  logical  SEPs  (L-SEPs)  and  demonstrat¬ 
ing  that  it  is  possible  to  automatically  infer  which  email  responses  are  acceptable 
with  respect  to  a  set  of  ultimately  desired  constraints  in  polynomial  time.  For  this 
model,  Section  4  also  describes  how  to  automatically  generate  explanations  for 
the  manager’s  interventions,  and  identifies  cases  where  such  explanations  can  be 
computed  in  polynomial  time.  Second,  Section  5  describes  a  model  of  decision- 
theoretic  SEPs  (D-SEPs)  that  alleviates  several  shortcomings  of  the  logical  model, 
and  presents  results  for  the  complexity  of  computing  optimal  policies  for  D-SEPs. 
Finally,  Section  6  discusses  implementation  issues  that  arise  for  semantic  email  and 
how  we  have  addressed  these  in  our  system,  and  Section  7  contrasts  our  approach 
with  related  work.  The  appendices  provides  proofs  for  all  of  the  theorems  given  in 
the  body  of  this  paper. 


2  Semantic  Email  Processes 

Our  formalization  of  SEPs  serves  several  goals.  First,  the  formalization  captures 
the  exact  meaning  of  semantic  email  and  the  processes  that  it  defines.  Second,  it 
clarifies  the  limitations  of  SEPs,  thereby  providing  the  basis  for  the  study  of  varia¬ 
tions  with  different  expressive  powers.  Finally,  given  the  formalization,  we  can  pose 
several  reasoning  problems  that  can  help  guide  the  creation  of  semantic  email  pro¬ 
cesses  as  well  as  manage  their  life  cycle.  We  emphasize  that  the  users  of  SEPs  are 
not  expected  to  understand  a  formalization  or  write  specifications  using  it.  Generic 
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Fig.  1.  The  invocation  and  execution  of  a  SEP.  The  originator  is  typically  a  person,  but  also 
could  be  an  automated  program.  The  originator  invokes  a  SEP  via  a  simple  web  interface, 
and  thus  need  not  be  trained  in  the  details  of  SEPs  or  even  understand  RDF. 


SEPs  are  written  by  trained  authors  (who  create  simple  constraints  or  utility  func¬ 
tions  to  represent  the  goal  of  a  process)  and  invoked  by  untrained  users.  The  seman¬ 
tic  email  system  then  coordinates  the  process  to  provide  the  formal  guarantees  we 
describe  later. 

Figure  1  illustrates  the  three  primary  components  of  a  SEP: 

•  Originator:  A  SEP  is  initiated  by  the  originator ,  who  is  typically  a  person, 
but  could  be  an  automated  program  or  agent. 

•  Manager:  The  originator  invokes  a  new  SEP  by  sending  a  message  to  the  se¬ 
mantic  email  manager.  The  manager  sends  email  messages  to  the  participants , 
handles  responses,  and  requests  changes  as  necessary  to  meet  the  originator’s 
goals.  The  manager  stores  all  data  related  to  the  process  in  an  RDF  supporting 
data  set,  which  may  be  configured  to  allow  queries  by  external  services  (or 
other  managers).  To  accomplish  its  tasks,  the  manager  may  also  utilize  exter¬ 
nal  services  such  as  inference  engines,  ontology  matchers,  and  other  Semantic 
Web  applications,  as  described  further  below.  The  manager  may  be  a  shared 
server  or  a  program  run  directly  by  the  originator. 

•  Participants:  The  participants  respond  to  messages  received  about  the  pro¬ 
cess.  A  participant  may  be  a  person,  a  standalone  program  (e.g.,  to  represent 
a  resource  such  as  a  conference  room),  or  a  software  agent  that  acts  on  behalf 
of  a  person  (e.g.,  to  automatically  respond  to  requests  where  possible,  defer¬ 
ring  others  to  the  person).  We  assume  that  email  addresses  uniquely  determine 
individuals  or  sets  of  potential  participants  in  the  process. 

Informally  speaking,  the  execution  of  a  process  is  achieved  by  the  supporting  data 
set  and  the  set  of  data  updates  that  email  recipients  make  as  they  respond.  In  the 
model  we  describe,  data  is  represented  as  a  set  of  relations  (i.e.,  the  relational 
database  model).  However,  as  the  application  domains  get  more  complex,  we  ex¬ 
pect  to  use  a  richer  representation  language.  To  enable  these  future  extensions  as 
well  as  interactions  with  other  Semantic  Web  applications,  our  system  implements 
this  representation  using  the  Jena  RDF  storage  system  [37]. 
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We  illustrate  our  formalization  with  the  running  example  of  a  “balanced  potluck.” 
The  originator  invokes  a  process  to  announce  the  potluck  and  ask  everyone  whether 
they  are  bringing  an  appetizer,  entree,  or  dessert.  The  originator  also  expresses  a  set 
of  goals  for  the  potluck.  For  example,  he  may  specify  that  the  number  of  appetizers, 
entrees,  or  desserts  should  differ  by  at  most  two.  Note  that,  while  this  particular 
problem  has  a  number  of  other  uses  (e.g.,  distributing  N  persons  evenly  among 
K  committees  or  time  slots),  it  is  just  an  example.  Both  our  formalization  and 
implementation  of  SEPs  support  a  much  broader  range  of  uses. 

The  manager  seeks  to  expedite  the  execution  of  this  process  and  to  achieve  the 
originator’s  goals.  There  are  a  number  of  ways  in  which  reasoning  can  enhance  the 
manager’s  operation: 

•  Predicting  responses:  The  manager  may  be  able  to  infer  the  likely  response 
of  some  participants  even  before  sending  any  requests.  For  instance,  the  man¬ 
ager  could  employ  another  semantic  web  application  or  data  source  to  detect 
that  a  suggested  meeting  time  is  unacceptable  for  a  certain  participant,  based 
on  information  from  calendars,  course  schedules,  or  other  processes.  The  man¬ 
ager  could  use  this  information  either  to  warn  the  originator  as  the  process  is 
being  created,  or  to  serve  as  a  surrogate  response  until  a  definitive  answer  is 
received.  Also,  the  manager  could  add  a  helpful  annotation  to  the  request  sent 
to  the  participant,  indicating  what  time  is  likely  to  be  a  conflict  and  why.  As 
suggested  above,  this  same  reasoning  could  also  be  profitably  employed  on  the 
participant’s  end,  where  an  agent  may  have  additional  information  about  the 
participant’s  schedule. 

•  Interpreting  responses:  Typically,  the  originator  will  provide  the  partici¬ 
pants  with  a  finite  set  of  choices  (e.g..  Appetizer ,  Entree,  Dessert). 
However,  suitable  reasoning  could  enable  substantially  more  flexibility.  For 
instance,  we  could  allow  a  potluck  participant  to  respond  with  any  value  (ei¬ 
ther  in  plain  text  or  in  some  formal  language).  Then,  the  manager  could  use 
a  combination  of  information  extraction  or  wrapper  techniques  (e.g.,  [15,31]) 
and/or  ontology  matching  algorithms  (e.g.,  [14,13])  to  map  the  participant’s 
response  into  the  potluck’s  ontology.  There  are  several  interesting  outcomes 
to  this  mapping.  First,  the  response  may  directly  map  to  one  of  the  original 
potluck  choices  (e.g.,  “Cake”  is  an  instance  of  Dessert).  Second,  the  re¬ 
sponse  may  map  to  multiple  choices  in  our  ontology  (e.g.,  “Jello  salad”  may 
be  both  an  Appetizer  and  a  Dessert).  In  this  case,  the  manager  might 
consider  the  response  to  be  half  of  an  appetizer  and  a  dessert,  or  postpone  the 
decision  to  a  later  time  and  classify  it  as  is  most  convenient.  2  Third,  the  re¬ 
sponse  may  not  map  to  any  given  choice,  but  may  still  be  a  subclass  of  Food 
(e.g.,  a  “Sorbet”  is  a  Palette  Cleanser);  here  the  manager  might  accept 
the  response  but  exclude  it  from  the  goal  calculations.  Fourth,  the  response 


2  This  a  very  simple  form  of  semantic  negotiation;  more  complex  techniques  could  also  be 
useful  [55]. 
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may  map  to  a  known  ontology  element  that  is  not  Food  (e.g.,  “A  hat”).  Fi¬ 
nally,  the  response  may  not  map  to  any  known  element.  In  these  latter  two 
cases,  the  manager  may  either  reject  the  response  or  notify  the  originator. 

•  Recommending  interventions:  Reasoning  can  also  assist  the  manager  with 
directing  the  process  towards  outcomes  consistent  with  the  originator’s  goals. 
For  instance,  if  the  manager  detects  that  a  potluck  process  is  becoming  unbal¬ 
anced,  it  could  refuse  to  accept  certain  responses,  request  changes  from  some 
participants,  or  warn  the  originator  that  further  action  is  needed.  In  this  case 
reasoning  is  needed  to  deduce  the  likely  outcome  of  a  process  from  the  current 
state,  and  the  likely  effects  of  possible  interventions. 

In  this  work  we  focus  on  using  reasoning  for  recommending  interventions,  leav¬ 
ing  the  other  two  items  for  future  work.  Specifically,  we  provide  two  different  ap¬ 
proaches  for  modeling  the  originator’s  goals  and  when  to  intervene.  In  the  logical 
model  (Sections  3  and  4),  the  originator  specifies  a  set  of  constraints  over  the  data 
set  that  should  be  satisfied  by  any  process  outcome,  while  in  the  decision-theoretic 
model  (Section  5)  the  originator  provides  a  function  representing  the  utility  of  pos¬ 
sible  process  outcomes.  Below  we  consider  each  in  turn,  discuss  possible  variants, 
and  present  results  for  fundamental  reasoning  tasks  that  can  determine  how  and 
when  the  manager  should  intervene. 


3  Logical  Model  of  SEPs 

We  now  introduce  our  model  of  a  logical  semantic  email  process  (L-SEP)  and 
analyze  important  inference  problems  for  this  model. 


3.1  Definition  of  L-SEP s 

A  L-SEP  is  a  5-tuple  A(P,  D,  R ,  M,  C-d)  with  parts  as  follows: 

Participants  P :  the  set  of  participants  in  the  process.  Note  that  P  may  include  the 
originator. 


Supporting  data  set  D :  the  set  of  relations  that  holds  all  data  related  to  the  process. 
The  initial  contents  of  D  are  specified  by  the  originator  (usually  to  be  a  set  of 
default  values  for  the  columns).  With  each  relation  in  D  we  associate  a  schema  that 
includes: 

•  a  relation  name  and  names,  data  types,  and  range  constraints  for  the  attributes. 
A  special  data  type  is  emailAddress,  whose  values  are  elements  of  the  set  P. 
Attributes  may  have  default  values. 
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•  possibly  a  distinguished  from  attribute,  of  type  email  Address,  which  means 
that  rows  in  the  relation  whose  from  value  is  p  can  only  result  from  messages 
from  the  participant  p.  The  from  attribute  may  be  declared  unique,  in  which 
case  every  participant  can  only  affect  a  single  row  in  the  table. 


Responses  R:  the  set  of  possible  responses  to  the  originator’s  email.  R  is  specified 
as  follows: 

•  Attributes:  the  set  of  attributes  in  D  that  are  affected  by  responses  from  partic¬ 
ipants.  This  set  of  attributes  cannot  include  any  from  attributes. 

•  Insert  or  Update:  a  parameter  specifying  whether  participants  can  only  add 
tuples,  only  modify  tuples,  or  both.  Recall  that  if  there  is  a  from  field  then  all 
changes  from  p  pertain  only  to  a  particular  set  of  tuples. 

•  Single  or  Many:  a  parameter  specifying  whether  participants  can  send  a  single 
response  or  more  than  one.  As  we  explain  in  the  next  section,  some  responses 
may  be  rejected  by  the  system.  By  single,  we  mean  one  non-rejected  message. 


Messages  M:  the  set  of  messages  that  the  manager  may  use  to  direct  the  process, 
e.g.,  to  remind  the  participants  to  respond  or  to  reject  a  participant’s  response. 


Constraints  Cd'  the  set  of  constraints  for  every  relation  in  D.  These  constraints 
Cd  are  specified  in  a  language  that  includes  conjunction  and  disjunction  of  atomic 
predicates.  Atomic  predicates  compare  two  terms,  or  a  term  with  a  set.  We  allow 
comparison  predicates  (=.  <,  <),  LIKE,  and  e,  jL  between  a  constant  and  an 

enumerated  finite  set.  A  term  may  be  a  constant,  an  attribute  variable  (the  value  of  a 
specific  attribute  in  a  row),  an  expression  combining  two  terms  with  any  arithmetic 
operator,  or  an  aggregate  applied  to  a  column  of  a  relation  (or  to  a  subset  of  the 
rows  that  satisfy  an  (in)equality  predicate). 

Example:  In  our  example,  D  contains  one  table  named  Potluck  with  two  columns: 
email,  a  from  attribute  of  type  emailAddress  and  declared  to  be  unique,  and 
bringing,  with  the  range  constraint  Potluck. bringing  e  {  not-coming,  ap¬ 
petizer,  entree,  dessert,  NULL  }.  The  set  of  possible  responses  R  is 
(not-coming,  appetizer,  entree,  dessert  }.  In  addition,  Cd  con¬ 
tains  a  few  constraint  formulas  similar  to  the  abstract  one  below,  specifying  that  the 
potluck  should  be  balanced: 

(count(*)  WHERE  bringing  =  ’dessert’)  < 

(count(*)  WHERE  bringing  =  ’appetizer’)  +  2 

Finally,  the  set  of  messages  in  our  example  includes  (1)  the  initial  message  an¬ 
nouncing  the  potluck  and  asking  what  each  person  is  bringing,  (2)  messages  in¬ 
forming  each  responder  whether  their  response  was  accepted  or  not,  (3)  a  reminder 
to  those  who  have  not  responded  2  days  before  the  potluck,  (4)  regular  messages 


8 


to  the  originator  reporting  the  status  of  the  responses,  and  (5)  a  message  to  the 
originator  in  the  event  that  everyone  has  responded. 

3.2  Inference  for  L-SEPs 

Given  the  formal  model  for  an  L-SEP  we  can  now  pose  a  wide  variety  of  inference 
problems,  whose  results  can  serve  to  assist  in  the  manager’s  operation.  This  section 
describes  the  first  such  inference  problem,  which  has  different  variations. 

The  core  problem  we  want  to  address  is  determining  whether  an  L-SEP  will  termi¬ 
nate  in  an  acceptable  state,  i.e.,  a  state  that  satisfies  Cd-  The  input  to  the  inference 
problem  includes  the  constraints  Cd  and  possibly  the  current  state  of  D  along  with 
a  response  r  from  a  participant.  The  output  of  the  inference  problem  is  a  condition 
that  we  will  check  on  D  and  r  to  determine  whether  to  accept  r.  In  our  discussion, 
we  assume  that  r  is  a  legal  response,  i.e.,  the  values  it  inserts  into  D  satisfy  the 
range  constraints  on  the  columns  of  D\  if  not,  the  manager  can  respond  with  error 
messages  until  a  legal  response  is  received.  Our  goal  is  to  automatically  determine 
whether  to  accept  r  given  the  current  state  and  Cd- 

The  space  of  possible  inference  problems  is  defined  by  several  dimensions: 

•  Necessity  vs.  possibility:  As  in  modal  logics  for  reasoning  about  future  states 
of  a  system  [48,18],  one  can  either  look  for  conditions  that  guarantee  that  any 
sequence  of  responses  ends  in  a  desired  state  (the  □  operator),  or  that  it  is 
possible  that  some  sequence  ends  in  a  desired  state  (the  O  operator). 

•  Assumptions  about  the  participants:  In  addition  to  assuming  that  all  re¬ 
sponses  are  legal,  we  can  consider  other  assumptions,  such  as:  (1)  all  the  par¬ 
ticipants  will  respond  to  the  message  or  (2)  the  participants  are  flexible,  i.e.,  if 
asked  to  change  their  response,  they  will  cooperate. 

•  The  type  of  output  condition:  At  one  extreme,  we  may  want  a  constraint  Cr 
that  the  manager  checks  on  D  when  a  response  r  arrives,  where  Cr  is  specified 
in  the  same  language  used  to  specify  Cd-  At  another  extreme,  we  may  produce 
an  arbitrary  procedure  with  inputs  D  and  r  that  determines  whether  to  accept 
r.  We  note  that  a  constraint  Cr  will  inevitably  be  weaker  than  an  arbitrary 
algorithm,  because  it  can  only  inspect  the  state  of  D  in  very  particular  ways. 
As  intermediate  points,  we  may  consider  constraints  Cr  in  more  expressive 
constraint  languages.  Note  that  in  cases  where  we  can  successfully  derive  Cr, 
we  can  use  database  triggers  to  implement  modifications  to  D  or  to  indicate 
that  r  should  be  rejected. 

As  a  very  simple  example,  consider  the  case  where  we  want  all  response  sequences 
to  end  in  an  acceptable  state,  we  make  no  assumptions  on  the  participants  except 
that  we  can  elicit  a  legal  response  from  them,  and  we  are  interested  in  deriving  a 
constraint  Cr  that  will  be  checked  when  a  response  arrives.  If  the  initial  state  of  D  is 
an  acceptable  state,  then  simply  setting  Cr  to  be  Cr)  provides  a  sufficient  condition; 
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i.e.,  we  only  let  the  data  set  D  be  in  states  that  satisfy  Co-  In  the  example  of  the 
balanced  potluck,  we  would  not  accept  a  response  with  a  dessert  if  that  would  lead 
to  having  3  more  desserts  than  entrees  or  appetizers.  For  a  giveaway  process,  we 
would  not  accept  a  request  that  caused  the  total  number  of  tickets  claimed  to  be 
more  than  the  number  that  is  available. 

In  many  cases,  such  a  conservative  strategy  will  be  overly  restrictive.  For  example, 
we  may  want  to  continue  accepting  desserts  so  long  as  it  is  still  possible  to  achieve 
a  balanced  potluck.  Furthermore,  this  approach  is  usable  only  when  the  constraints 
are  initially  satisfied,  even  before  any  responses  are  received,  and  thus  greatly  limits 
the  types  of  goals  that  can  be  expressed.  This  leads  us  to  the  following  inference 
problem. 


3.3  Ultimate  Satisfiability 

We  now  describe  our  central  result  concerning  inference  for  L-SEPs.  Our  goal  is  to 
find  necessary  and  sufficient  conditions  for  accepting  a  response  from  a  participant. 
To  do  that,  we  cut  across  the  above  dimensions  as  follows.  Suppose  we  are  given 
the  data  set  D  after  0  or  more  responses  have  been  accepted,  and  a  new  response  r. 
Note  that  D  does  not  necessarily  satisfy  Co,  either  before  or  after  accepting  r.  The 
manager  will  accept  r  if  it  is  possible  that  it  will  lead  to  a  state  satisfying  CD  (i.e., 
considering  the  O  temporal  operator).  We  do  not  require  that  the  acceptance  condi¬ 
tion  be  expressed  in  our  constraint  language,  but  we  are  concerned  about  whether 
it  can  be  efficiently  verified  on  D  and  r.  We  assume  that  D  defines  some  constant 
number  of  attributes  (e.g.,  emailAddress ,  bringing).  Furthermore,  we  as¬ 
sume  that  participants  can  only  update  their  (single)  row,  and  only  do  so  once. 

Definition  3.1  (ultimate  satisfiability)  Given  a  data  set  D,  a  set  of  constraints  Co 
on  D,  and  a  response  r  £  R ,  we  say  that  D  is  ultimately  satisfiable  w.r.t.  r  if  there 
exists  a  sequence  of  responses  from  the  participants,  beginning  with  r,  that  will  put 
D  in  a  state  that  satisfies  Cp.  □ 

In  what  follows,  let  C  be  our  constraint  language  where  we  allow  both  conjunction 
and  disjunction  of  atomic  predicates.  A  term  in  a  predicate  of  CD  may  select  a  group 
of  rows  in  an  attribute  A,  and  aggregate  the  value  of  the  corresponding  values  in  an 
attribute  B.  We  consider  the  aggregation  functions  COUNT,  MIN,  MAX,  SUM,  and 
AVERAGE.  In  addition,  we  define  the  following: 

Definition  3.2  (bounded  constraints)  Given  a  data  set  D  and  a  set  of  constraints 
Co  on  D,  we  say  that  Co  is  bounded  iff  one  of  the  following  holds: 

•  Domain-bounded:  the  predicates  of  Cd  only  refer  to  attributes  whose  domain 
size  is  at  most  some  constant  L. 

•  Constant-bounded:  the  predicates  of  Cd  refer  to  at  most  K  distinct  constants, 

and  the  only  aggregate  used  by  Cd  is  COUNT.  □ 
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All  of  the  examples  in  this  paper  may  be  described  by  constraints  that  satisfy  the 
constant-bounded,  COUNT-only  condition  above,  while  the  domain-bounded  case 
may  be  useful  for  SEPs  that  require  more  complex  interactions.  Using  this  defini¬ 
tion,  we  can  show  that  ultimate  satisfiability  is  difficult  in  general,  but  much  more 
tractable  if  the  constraints  are  bounded: 

Theorem  1  Let  A  be  an  L-SEP  with  N  participants  and  constraints  C d-  If  Cd  may 
be  any  set  of  constraints  permitted  by  the  language  C,  then  ultimate  satisfiability 
is  NP -complete  in  N.  If  Co  is  bounded,  then  determining  ultimate  satisfiability  is 
polynomial  time  in  N  and  Co  \ . 

As  an  example  of  applying  this  theorem  to  the  balanced  potluck,  suppose  a  new 
dessert  response  arrives.  At  that  point,  the  inference  procedure  will  (1)  determine 
the  maximal  number  of  people  who  may  come  to  the  potluck  (i.e.,  the  number  of 
participants  minus  the  number  of  people  who  replied  not -coming),  (2)  check 
that  even  if  the  dessert  response  is  accepted,  then  there  are  still  enough  people  who 
have  not  answered  such  that  the  ultimate  set  of  dishes  could  be  balanced.  Similar 
reasoning  applies  to  other  processes,  e.g.,  to  ensure  that  at  least  one  person  will 
sign  up  for  each  spot  in  a  colloquium  series. 

The  theorem  is  proved  by  enumerating  representative  states  of  the  data  set,  each 
of  which  corresponds  to  a  number  of  potential  states  that  are  all  equivalent  with 
respect  to  the  constraints.  The  key  is  to  express  the  constraints  in  terms  of  variables 
representing  aggregates  on  the  number  of  participants  with  each  response.  See  the 
appendices  for  the  complete  proof. 

In  comparison  to  related  work,  the  challenge  here  is  reasoning  about  the  possi¬ 
ble  relationships  between  aggregate  values  (current  and  future),  given  a  particular 
state  of  D.  Reasoning  about  aggregation  has  received  significant  attention  in  the 
query  optimization  literature  [50,33,11,20]  and  some  in  the  description  logic  liter¬ 
ature  (e.g.,  [3]).  This  body  of  work  considered  the  problem  of  optimizing  queries 
with  aggregation  by  moving  predicates  across  query  blocks,  and  reasoning  about 
query  containment  and  satisfiability  for  queries  involving  grouping  and  aggrega¬ 
tion.  In  contrast,  our  result  involves  considering  the  current  state  of  the  database  to 
determine  whether  it  can  be  brought  into  a  state  that  satisfies  a  set  of  constraints. 
Furthermore,  since  C'd  may  involve  several  grouping  columns  and  aggregations, 
they  cannot  be  translated  into  single-block  SQL  queries,  and  hence  the  contain¬ 
ment  algorithms  will  not  carry  over  to  our  context. 

To  the  best  of  our  knowledge,  formalisms  for  reasoning  about  workflow  [44,43] 
or  about  temporal  properties  of  necessity  and  possibility  have  not  considered  rea¬ 
soning  about  aggregation.  For  instance,  Abiteboul  et  al.  [1]  define  a  notion  of 
goal  reachability  for  relational  transducers  that  is  similar  to  our  ultimate  satisfi¬ 
ability  (see  also  [22]  for  extensions  to  this  model  and  a  survey  of  other  related 
work).  Various  restrictions  on  the  model  allow  decidability  of  goal  reachability  in 
P,  NP,  or  NEXPTIME,  but  none  of  these  restrictions  permit  goals  involving  aggre- 
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gation.  Likewise,  workflow  formalisms  have  generally  been  restricted  to  reasoning 
about  temporal  and  causality  constraints.  Such  formalisms  could  potentially  con¬ 
vert  aggregation  constraints  to  temporal  constraints  by  enumerating  all  possible 
data  combinations,  but  this  may  result  in  an  exponential  number  of  states.  One  ex¬ 
ception  is  the  recent  work  of  Senkul  et  al.  [52],  who  extend  workflows  to  include 
resource  constraints  based  on  aggregation.  Each  such  constraint,  however,  is  re¬ 
stricted  to  performing  a  single  aggregation  with  no  grouping  (and  thus  could  not 
express  the  potluck  constraint  given  in  the  earlier  example).  In  addition,  their  so¬ 
lution  is  based  on  general  constraint  solving  and  thus  will  take  exponential  time  in 
the  worst  case.  We  have  shown,  however,  that  in  our  domain  L-SEPs  can  easily 
express  more  complex  aggregation  constraints  while  maintaining  polynomial-time 
inference  complexity  for  bounded  constraints. 


4  Explanation  Generation  for  L-SEPs 

While  executing,  an  L-SEP  utilizes  rejections  to  influence  the  eventual  outcome. 
However,  the  success  of  these  interventions  depends  on  the  extent  to  which  they  are 
understood  by  the  participants.  For  instance,  the  rejection  “Sorry,  the  only  dates  left 
are  May  7  and  May  14”  is  much  more  likely  to  elicit  cooperation  from  a  participant 
in  a  seminar  scheduling  SEP  than  the  simpler  rejection  “Sorry,  try  again.”  For  a 
particular  set  of  constraints,  the  author  of  a  SEP  could  manually  specify  how  to 
create  such  explanations,  but  this  task  can  be  very  difficult  when  constraints  inter¬ 
act  or  depend  on  considering  possible  future  responses.  Thus,  below  we  consider 
techniques  for  automatically  generating  explanations  based  on  what  responses  are 
acceptable  now  and  why  the  participant’s  original  response  was  not  acceptable. 

We  begin  by  defining  more  precisely  a  number  of  relevant  terms.  Given  an  L- 
SEP,  the  current  state  D  is  the  state  of  the  supporting  data  set  given  all  of  the 
responses  that  have  been  received  so  far.  We  assume  that  the  number  of  participants 
is  known  and  that  each  will  eventually  respond.  Following  the  earlier  discussion 
regarding  necessity  vs.  possibility,  we  allow  constraint  satisfaction  to  be  defined  in 
two  different  ways: 

Definition  4.1  (MustConstraint)  A  MustConstraint  C  is  a  constraint  that  is 
satisfied  in  state  D  iff  evaluating  C  over  D  yields  True.  □ 

Definition  4.2  (PossiblyConstraint)  A  PossiblyConstraint  C  is  a  con¬ 
straint  that  is  ultimately  satisfiable  in  state  D  if  there  exists  a  sequence  of  responses 
from  the  remaining  participants  that  leads  to  a  state  D'  so  that  evaluating  C  over 
D'  yields  True.  □ 


For  simplicity,  we  assume  that  the  constraints  Cp  are  either  all  MustCon- 
straints  or  all  PossiblyConstraint s,  though  our  results  for  Possi¬ 
blyConstraint  s  also  hold  when  Cp  contains  both  types. 
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4.1  Acceptable  Responses 


Often  the  most  practical  information  to  provide  to  a  participant  whose  response 
led  to  an  intervention  is  the  set  of  responses  that  would  be  “acceptable”  (e.g.,  “An 
Appetizer  or  Dessert  would  be  welcome”  or  “Sorry,  I  can  only  accept  requests 
for  2  tickets  or  fewer  now”).  This  section  briefly  considers  how  to  calculate  this 
acceptable  set. 

Definition  4.3  (acceptable  set)  Let  A  be  an  L-SEP  with  current  state  D  and  con¬ 
straints  CD  on  D.  Then,  the  acceptable  set  A  of  A  is  the  set  of  legal  responses  r 
such  that  D  would  still  be  satisfiable  w.r.t.  C'o  after  accepting  r.  □ 

For  a  MustConstraint,  this  satisfiability  testing  is  easy  to  do  and  we  can  com¬ 
pute  the  acceptable  set  by  testing  some  small  set  of  representative  responses.  For  a 
PossiblyConstraint,  the  situation  is  more  complex: 

Theorem  2  Let  A  be  an  F-SEP  with  N  participants  and  current  state  D.  If  the 
constraints  Co  may  be  any  set  of  constraints  permitted  by  the  language  C,  then 
computing  the  acceptable  set  A  of  A  is  NP-hard  in  N.  If  Co  is  bounded,  then  this 
problem  is  polynomial  time  in  N,  \A\,  and  Co  \ ■ 

In  this  case  we  can  again  compute  the  acceptable  set  by  testing  satisfiability  over 
some  small  set  of  representative  values;  this  testing  is  polynomial  iff  Co  is  bounded 
(Theorem  1).  In  addition,  if  we  represent  A  via  a  set  of  ranges  of  acceptable  values, 
instead  of  explicitly  listing  every  acceptable  value,  then  the  total  time  is  polynomial 
in  only  N  and  \Co\- 


4.2  Explaining  Interventions 


In  some  cases,  the  acceptable  set  alone  may  not  be  enough  to  construct  a  useful 
explanation.  For  instance,  suppose  an  F-SEP  invites  4  professors  and  20  students 
to  a  meeting  that  at  least  3  professors  and  a  quorum  of  10  persons  (professors  or 
students)  must  attend.  When  requesting  a  change  from  a  professor,  explaining  why 
the  change  is  needed  (e.g.,  “We  need  you  to  reach  the  required  3  professors”)  is 
much  more  effective  than  simply  informing  them  what  response  is  desired  (e.g., 
“Please  change  to  Yes”).  A  clear  explanation  both  motivates  the  request  and  rules 
out  alternative  reasons  for  the  request  (e.g.,  “We  need  your  help  reaching  quorum”) 
that  may  be  less  persuasive  (e.g.,  because  many  students  could  also  help  reach  quo¬ 
rum).  This  section  discusses  how  to  generate  explanations  for  an  intervention  based 
on  identifying  the  constraint(s)  that  led  to  the  intervention.  We  do  not  discuss  the 
additional  problem  of  translating  these  constraints  into  a  natural  language  suitable 
for  sending  to  a  participant,  but  note  that  even  fairly  simple  explanations  (e.g.,  “Too 
many  Appetizers  (10)  vs.  Desserts  (3)”)  are  much  better  than  no  explanation. 
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Conceptually,  an  L-SEP  decides  to  reject  a  response  based  on  constructing  a  proof 
tree  that  shows  that  some  response  r  would  prevent  constraint  satisfaction.  How¬ 
ever,  this  proof  tree  may  be  much  too  large  and  complex  to  serve  as  an  explana¬ 
tion  for  a  participant.  This  problem  has  been  investigated  before  for  expert  sys¬ 
tems  [45,54],  constraint  programming  [26],  description  logic  reasoning  [40],  and 
more  recently  in  the  context  of  the  Semantic  Web  [41].  These  systems  assumed 
proof  trees  of  arbitrary  complexity  and  handled  a  wide  variety  of  possible  deduc¬ 
tion  steps.  To  generate  useful  explanations,  key  techniques  included  abstracting 
multiple  steps  into  one  using  rewrite  rules  [40,41],  describing  how  general  princi¬ 
ples  were  applied  in  specific  situations  [54],  and  customizing  explanations  based 
on  previous  utterances  [10]. 

In  our  context,  the  proof  trees  have  a  much  simpler  structure  that  we  can  exploit. 
In  particular,  proofs  are  based  only  on  constraint  satisfiability  (over  one  state  or 
all  possible  future  states),  and  each  child  node  adds  one  additional  response  to  the 
parent’s  state  in  a  very  regular  way.  Consequently,  we  will  be  able  to  summarize 
the  proof  tree  with  a  very  simple  type  of  explanation.  These  proof  trees  are  defined 
as  follows: 

Definition  4.4  (proof  tree)  Given  an  L-SEP  A,  current  state  D,  constraints  Cd, 
and  a  response  r,  we  say  that  P  is  a  proof  tree  for  rejecting  r  on  D  iff: 

•  P  is  a  tree  where  the  root  is  the  initial  state  D. 

•  The  root  has  exactly  one  child  Dr,  representing  the  state  of  D  after  adding  r. 

•  If  Cd  is  all  MustConstraint  s,  then  Dr  is  the  only  non-root  node. 

•  If  Cd  is  all  PossiblyConstraint s,  then  for  every  node  n  that  is  Dr  or 
one  of  its  descendants,  n  has  all  children  that  can  be  formed  by  adding  a  single 
additional  response  to  the  state  of  n.  Thus,  the  leaf  nodes  are  only  and  all  those 
possible  final  states  (e.g.,  where  every  participant  has  responded)  reachable 
from  Dr. 

•  For  every  leaf  node  /,  evaluating  CD  over  the  state  of  l  yields  False.  □ 

Figure  2A  illustrates  a  proof  tree  for  MustConstraint s.  Because  accepting  r 
leads  to  a  state  where  some  constraint  (e.g.,  Cf)  is  not  satisfied,  r  must  be  rejected. 
Likewise,  Figure  2B  shows  a  proof  tree  for  PossiblyConstraint  s,  where  Cp 
and  Cq  represent  the  professor  and  quorum  constraints  from  the  example  described 
above.  Since  we  are  trying  to  prove  that  there  is  no  way  for  the  constraints  to  be 
ultimately  satisfied  (by  any  outcome),  this  tree  must  be  fully  expanded.  For  this  tree, 
every  leaf  (final  outcome)  does  not  satisfy  some  constraint,  so  r  must  be  rejected. 

We  now  define  a  simpler  explanation  based  upon  the  proof  tree: 

Definition  4.5  (sufficient  explanation)  Given  an  L-SEP  A,  current  state  D,  con¬ 
straints  Cd,  and  a  response  r  such  that  a  proof  tree  P  exists  for  rejecting  r  on  D, 
then  we  say  that  E  is  a  sufficient  explanation  for  rejecting  r  iff, 

•  E  is  a  conjunction  of  constraints  that  appear  in  Cp,  and 

•  for  every  leaf  node  /  in  P,  evaluating  E  over  the  state  of  l  yields  False.  □ 
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A.)  MustConstraint 


B.)  PossiblyConstraint 


D0  (initial  state) 


CS,CT  D, 


Fig.  2.  Examples  of  proof  trees  for  rejecting  response  r.  Each  node  is  a  possible  state  of 
the  data  set,  and  node  labels  arc  constraints  that  arc  not  satisfied  in  that  state.  In  both  cases, 
response  r  must  be  rejected  because  every  leaf  node  (shaded  above)  does  not  satisfy  some 
constraint. 

Intuitively,  a  sufficient  explanation  E  justifies  rejecting  r  because  E  covers  every 
leaf  node  in  the  proof  tree,  and  thus  precludes  ever  satisfying  Cp.  Note  that  while 
the  proof  tree  for  rejecting  r  is  unique  (modulo  the  ordering  of  child  nodes),  an 
explanation  is  not.  For  instance,  an  explanation  based  on  Figure  2A  could  be  C's, 
CT,  or  65  ACV-  Likewise,  a  valid  explanation  for  Figure  2B  is  CpACq  (e.g.,  no  way 
satisfy  both  the  professor  and  quorum  constraints)  but  a  more  precise  explanation 
is  just  CP  (e.g.,  no  way  to  satisfy  the  professor  constraint).  The  smaller  explanation 
is  often  more  compelling,  as  we  argued  for  the  meeting  example,  and  thus  to  be 
preferred  [12].  In  general,  we  wish  to  find  an  explanation  of  minimum  size  (i.e., 
with  the  fewest  conjuncts): 

Theorem  3  Given  an  L-SEP  A  with  N  participants,  current  state  D,  constraints 
Co,  and  a  response  r,  if  Co  consists  o/'Mu  stConstraints,  then  finding  a  min¬ 
imum  sufficient  explanation  E  for  rejecting  r  is  polynomial  time  in  N  and  Cp  j . 
If  Co  consists  o/'PossiblyConst  raint  s,  then  this  problem  is  NP-hard  in  N 
and  NP -hard  in  Cp  \ . 

Thus,  computing  a  minimum  explanation  is  feasible  for  MustConstraint  s  but 
likely  to  be  intractable  for  PossiblyConstraint  s.  For  the  latter,  the  difficulty 
arises  from  two  sources.  First,  checking  if  any  particular  E  is  a  sufficient  explana¬ 
tion  is  NP-hard  in  N  (based  on  a  reduction  from  ultimate  satisfiability);  this  makes 
scaling  SEPs  to  large  numbers  of  participants  difficult.  Second,  finding  a  mini¬ 
mum  such  explanation  is  NP-hard  in  the  number  of  constraints  (by  reduction  from 
SET-COVER  [23]);  this  makes  explanation  generation  for  complex  goals  challeng¬ 
ing.  Fortunately,  in  many  common  cases  we  can  simplify  this  problem  to  permit  a 
polynomial  time  solution: 

Theorem  4  Given  an  L-SEP  A  with  N  participants,  current  state  D,  constraints 
Cp,  and  a  response  r,  if  Co  is  bounded  and  the  size  of  a  minimum  explanation 
is  no  more  than  some  constant  J,  then  computing  a  minimum  explanation  E  is 
polynomial  time  in  N  and  \Co\- 
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This  theorem  holds  because  a  candidate  explanation  E  can  be  checked  in  polyno¬ 
mial  time  when  the  constraints  are  bounded,  and  restricting  E  to  at  most  size  J 
means  that  the  total  number  of  explanations  that  must  be  considered  is  polynomial 
in  the  number  of  constraints.  Both  of  these  restrictions  are  quite  reasonable.  As 
previously  mentioned,  bounded  constraints  permit  a  wide  range  of  functionality. 
Likewise,  SEP  explanations  are  most  useful  to  the  participants  when  they  contain 
only  a  small  number  of  constraints,  and  this  is  adequate  for  many  SEPs  (as  in  the 
meeting  example  above).  If  no  sufficient  explanation  of  size  J  exists,  the  system 
could  either  choose  the  best  explanation  of  size  J  (to  maintain  a  simple  explana¬ 
tion),  approximate  the  minimum  explanation  with  a  greedy  algorithm,  or  fall  back 
on  just  providing  the  participant  with  the  acceptable  set  described  in  the  previous 
section. 


5  Decision-theoretic  model 


The  logical  model  of  SEPs  described  above  supports  a  number  of  useful  inferences 
that  have  both  theoretical  and  practical  applications.  This  model,  however,  has  a 
number  of  shortcomings.  First,  L-SEPs,  like  logical  theories  in  general,  make  no 
distinctions  among  unsatisfied  outcomes.  In  our  example,  there  is  no  way  for  L- 
SEPs  to  strive  for  a  “nearly-balanced”  potluck,  since  all  unbalanced  potlucks  are 
equivalently  undesirable.  Second,  an  L-SEP  ignores  the  cost  of  the  actions  taken 
in  pursuit  of  its  goals.  For  instance,  a  potluck  L-SEP  will  always  reject  a  response 
that  results  in  unsatisfiable  constraints,  even  if  rejecting  that  response  (e.g.,  from 
an  important  official)  may  produce  far  worse  effects  than  a  slightly  unbalanced 
potluck.  Finally,  L-SEPs  make  a  very  strong  assumption  that  participants  are  al¬ 
ways  willing  to  change  their  responses  if  rejected.  For  instance,  participants  in  a 
meeting  scheduling  process  may  be  somewhat  accommodating,  but  may  refuse  to 
modify  a  rejected  response  due  to  other  commitments. 


To  address  these  limitations,  we  offer  a  decision-theoretic  approach.  We  describe 
the  goal  of  a  decision- theoretic  SEP  (D-SEP)  by  a  utility  function  over  the  out¬ 
come  of  the  process  that  takes  into  consideration  the  cost  of  all  actions  required 
to  achieve  that  outcome.  In  addition,  instead  of  rejecting  responses,  the  decision- 
theoretic  model  sometimes  suggests  that  participants  modify  their  choices.  For  in¬ 
stance,  the  balanced  potluck  uses  a  utility  function  that  measures  the  extent  to  which 
the  final  meal  selection  is  balanced,  minus  the  costs  (social  or  otherwise)  of  asking 
some  participants  to  switch  their  responses.  Below  we  formalize  this  model  and 
then  examine  the  tractability  of  finding  optimal  policies  for  it. 
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5.1  Definition  of  D-SEPs 


A  decision-theoretic  SEP  is  a  6-tuple,  S(P,  S,  V,  A,  U,  T ).  Note  that  the  first  five 
components  of  this  tuple  correspond  roughly  to  the  five  components  in  our  model 
for  L-SEPs. 

•  Participants  P:  the  set  of  participants,  of  size  N. 

•  States  S:  the  set  of  possible  states  of  the  system.  The  state  describes  both 
the  current  responses  received  and  the  outgoing  change  requests  sent  by  the 
system. 

•  Values  V :  the  set  of  possible  values  for  participants  to  choose  from  (e.g.,  V  = 

{appetizer,  entree ,  dessert}). 

•  Actions  A:  the  set  of  actions  available  to  the  system  after  sending  out  the  initial 
message.  Actions  we  consider  are  NoOp  (do  nothing  until  the  next  message 
arrives),  SWV  (ask  a  participant  to  switch  their  response  from  v  to  something 
else),  or  Halt  (enter  a  terminal  state,  typically  only  permitted  when  a  message 
has  been  received  from  every  participant).  Other  variants  of  actions  are  also 
useful  (e.g.,  ask  a  participant  to  switch  from  v  to  a  particular  value  w);  such 
additions  do  not  fundamentally  change  the  model  or  our  complexity  results. 

•  Utilities  U (s,  a):  the  utility  from  executing  action  a  in  state  s.  For  the  potluck 
example,  U ( s ,  SWV)  is  the  (negative)  utility  from  making  a  change  suggestion, 
while  U (s,  Halt )  is  the  utility  based  on  the  final  potluck  balance. 

•  Transitions  T(s,  a,  s'):  the  probability  that  the  system  will  transition  to  state 
s'  after  performing  action  a  in  state  s.  However,  rather  than  having  to  specify  a 
probability  for  each  transition,  these  are  computed  from  a  smaller  set  of  build¬ 
ing  blocks.  For  instance,  pv  is  the  probability  that  a  participant  will  originally 
respond  with  the  value  v;  pvw  is  the  probability  that,  when  asked  to  switch 
from  the  choice  v,  a  participant  will  change  their  response  to  w  ( pvv  is  the 
probability  that  a  participant  refuses  to  switch). 

The  execution  of  the  process  proceeds  in  discrete  steps,  where  at  each  step  the 
manager  decides  upon  an  action  to  take  (possibly  NoOp).  The  outcome  of  this 
action,  however,  is  uncertain  since  the  manager  is  never  sure  of  how  participants 
will  respond.  The  transition  function  T()  models  this  uncertainty. 

A  policy  7r  describes  what  action  the  manager  will  take  in  any  state,  while  w(s) 
denotes  the  action  that  the  manager  will  take  in  a  particular  state  s.  An  optimal 
policy  7 r*  is  a  policy  that  maximizes  the  expected  utility  U (5)  of  the  process,  where 

U (<5)  =  U (si,  o.i)  +  U (s 2,  af)  +  ...  +  U ( Sj ,  afi) 

for  the  sequence  of  states  and  actions  {(si,  ai), ...,  (sj,  Halt)}. 

D-SEPs  are  a  special  case  of  Markov  Decision  Processes  (MDPs),  a  well-studied 
formalism  for  situations  where  the  outcome  of  performing  an  action  is  governed 
by  a  stochastic  function  and  costs  are  associated  with  state  transitions  [49].  Conse- 
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quently,  we  could  find  the  optimal  policy  for  a  D-SEP  by  converting  it  to  an  MDP 
and  using  known  MDP  policy  solvers. 3  However,  this  would  not  exploit  the  special 
characteristics  of  D-SEPs  that  permit  more  efficient  solutions,  which  we  consider 
below. 

5.2  Variations  of  D-SEPs 

As  with  our  logical  model,  the  space  of  possible  D-SEPs  is  defined  by  several 
dimensions: 

•  Restrictions  on  making  suggestions:  Most  generally,  the  manager  may  be 
allowed  to  suggest  changes  to  the  participants  at  any  time ,  and  to  do  so  repeat¬ 
edly.  To  be  more  user-friendly,  we  may  allow  the  manager  to  make  suggestions 
anytime,  but  only  once  per  participant.  Alternatively,  if  users  may  be  expected 
to  make  additional  commitments  soon  after  sending  their  response  (e.g.,  pur¬ 
chasing  ingredients  for  their  selected  dish),  then  we  may  require  the  manager 
to  respond  with  any  suggestion  immediately  after  receiving  a  message,  before 
any  additional  messages  are  processed. 

•  Assumptions  about  the  participants:  In  addition  to  the  assumed  probabili¬ 
ties  governing  participant  behavior,  we  may  also  wish  to  assume  that  all  par¬ 
ticipants  will  eventually  respond  to  each  message  they  receive.  Furthermore, 
we  might  assume  that  participants  will  respond  immediately  to  any  suggestions 
that  they  receive  (particularly  if  the  manager  also  responds  immediately  to  their 
original  message),  or  instead  that  they  can  respond  to  suggestions  anytime. 

•  The  type  of  utility  functions:  At  one  extreme,  we  might  allow  complex  utility 
functions  based  upon  the  individual  responses  of  the  participants  (e.g.,  “+97  if 
Jay  is  bringing  dessert”).  Often,  however,  such  precision  is  unnecessary.  For 
instance,  all  potluck  outcomes  with  8  desserts  and  1  entree  have  the  same  low 
utility,  regardless  of  who  is  bringing  what  dish. 

Below  we  consider  the  impact  of  these  variations  on  the  complexity  of  computing 
the  optimal  policy. 

5.3  Computing  the  Optimal  Policy 

In  this  section  we  examine  the  time  complexity  of  computing  the  optimal  policy  n* 
for  a  D-SEP.  We  begin  by  considering  a  D-SEP  with  an  arbitrary  utility  function 
and  then  examine  how  restrictions  to  the  utility  function  and  the  permitted  quantity 


3  Specifically,  D-SEPs  arc  “Stochastic  Shortest-Path”  MDPs  where  the  terminal  state  is 
reachable  from  every  state,  so  an  optimal  policy  is  guaranteed  to  exist  [5].  Incorporating 
additional  features  from  temporal  MDPs  [9]  would  enable  a  richer  model  for  D-SEPs 
(e.g.,  scheduling  a  meeting  should  be  completed  before  the  day  of  the  meeting).  However, 
existing  solution  techniques  for  TMDPs  do  not  scale  to  the  number  of  participants  required 
for  semantic  email. 
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and  timing  of  suggestions  make  computing  7i*  more  tractable.  In  all  cases  we  as¬ 
sume  that  the  participants  will  eventually  respond  to  each  message  and  suggestion 
that  they  receive.  (We  can  relax  this  assumption  by  representing  in  the  model  the 
probability  that  a  participant  will  not  respond  to  a  message.)  The  following  theorem 
is  proved  by  reduction  from  QBF  (quantified  boolean  formula)  and  the  EXPTIME- 
hard  game  G4  [53,34]: 

Theorem  5  Let  5  be  a  D-SEP  with  N participants  where  the  utility  U (s,  a)  is  any 
deterministic  function  over  the  state  s  and  the  current  action  a.  If  the  manager 
can  send  only  a  bounded  number  of  suggestions  to  each  participant,  then  deter¬ 
mining  7 r*  is  PSPACE-hard  in  N.  If  the  manager  can  send  an  unlimited  number  of 
suggestions,  then  this  problem  is  EXPTIME-hard  in  N.  The  corresponding  prob¬ 
lems  of  determining  if  the  expected  utility  of  it*  for  5  exceeds  some  constant  6  are 
PSPACE-complete  and  EXPTIME-complete,  respectively.  □ 

Thus,  for  the  case  of  arbitrary  utility  functions  determining  7 r*  for  a  D-SEP  is 
impractical  for  large  values  of  N.  (Conversion  to  an  MDP  offers  little  help,  since 
the  MDP  would  require  a  number  of  states  exponential  in  N.)  Note  that  this  is 
a  significant  limitation,  since  for  many  D-SEPs  it  is  natural  to  wish  to  scale  to 
large  numbers  of  participants  (e.g.,  for  large  meetings  or  company-wide  surveys). 
Below,  we  begin  to  make  the  calculation  of  n*  more  tractable  by  restricting  the  type 
of  utility  function: 

Definition  5.1  (K-Partitionable)  The  utility  function  U(s,a )  of  a  D-SEP  is  K- 
partitionable  if  it  can  be  expressed  solely  in  terms  of  the  variables  a,C i, ...,  C'k 
where  a  is  the  current  action  chosen  by  the  manager  and  each  Ci  is  the  number  of 
participants  who  have  responded  with  value  V)  in  state  s.  □ 

Intuitively,  a  utility  function  is  K-partitionable  if  what  matters  is  the  number  of  par¬ 
ticipants  that  belong  to  each  of  a  fixed  number  of  K  groups,  rather  than  the  specific 
participants  in  each  of  these  groups.  For  instance,  the  utility  function  of  our  exam¬ 
ple  potluck  is  4-partitionable,  because  all  that  matters  for  evaluating  current  and 
future  utilities  is  the  current  number  of  participants  that  have  responded  Appe¬ 
tizer,  Entree,  Dessert ,  and  Not-Coming.  In  this  case  a  simple  utility 
function  might  be: 

U(s,  Halt )  =  -a(\CA  -  CE |2  +  \CA  -  CD |2  +  \CE  -  CD |2) 

U(s,SWv)  =  -l 

where  a  is  a  scaling  constant  and  CA,CE,  and  CD  are  the  numbers  of  appetizers, 
entrees,  and  desserts,  respectively.  Note  that  the  maximum  utility  here  is  zero. 

A  K-partitionable  utility  function  is  analogous  to  the  COUNT-only  constraint  lan¬ 
guage  of  Theorem  1.  As  with  Theorem  1,  we  could  allow  more  complex  utility 
functions  (e.g.,  with  variables  representing  the  MAX,  SUM,  etc.  of  the  underlying 
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responses);  with  suitable  restrictions,  such  functions  yield  polynomial  time  results 
similar  to  those  described  below.  Note,  however,  that  the  simpler  K-partitionable 
definition  is  still  flexible  enough  to  support  all  of  the  SEPs  discussed  in  this  paper. 
In  particular,  a  K-partitionable  utility  function  may  still  distinguish  among  differ¬ 
ent  types  of  people  by  counting  responses  differently  based  on  some  division  of 
the  participants.  This  technique  increases  the  effective  value  of  K ,  but  only  by  a 
constant  factor.  For  instance,  the  utility  function  for  a  meeting  scheduling  process 
that  desires  to  have  the  number  of  faculty  members  attending  (CyesF)  be  at  least 
three  and  the  number  of  students  attending  ( CyeSjs )  be  as  close  as  possible  to  five, 
while  strongly  avoiding  asking  faculty  members  to  switch,  might  be: 


U(s,  Halt )  =  —a[max( 3  —  CyeSj p,  0)]2  —  (3\ CyeSjs  —  5|2 
U(s,  SWno,F)  =  -10 
U{s,SWno>s)  =  - 1 

A  D-SEP  that  may  make  an  unlimited  number  of  suggestions  but  that  has  a  K- 
partitionable  utility  function  can  be  represented  as  an  “infinite-horizon”  MDP  with 
just  0(N2K)  reachable  states.  Consequently,  the  D-SEP  may  be  solved  in  time 
polynomial  in  N  with  the  use  of  linear  programming  (LP),  though  alternative  meth¬ 
ods  (e.g.,  policy  iteration,  simplex-based  LP  solvers)  that  do  not  guarantee  polyno¬ 
mial  time  may  actually  be  faster  in  practice  due  to  the  large  polynomial  degree  of 
the  former  approach  [35]. 

Furthermore,  if  we  also  restrict  the  system  to  send  only  one  suggestion  to  any  par¬ 
ticipant  (likely  a  desirable  property  in  any  case),  then  computing  the  optimal  policy 
becomes  even  more  tractable: 

Theorem  6  Let  5  be  a  D-SEP  with  N  participants  where  U(s.  a)  is  K- 
partitionable  for  some  constant  K  and  where  the  system  is  permitted  to  send  at 
most  one  suggestion  to  any  participant.  Then  n*  for  5  can  be  determined  in  0(N3K) 
time.  (If  the  system  can  send  at  most  L  suggestions  to  any  participant,  then  the  total 
time  needed  is  0(N(-2L+1^K).)  □ 

Table  1  summarizes  the  results  presented  above  as  well  as  a  few  other  interest¬ 
ing  cases  (“Immediate”  and  “Synchronous”).  These  results  rely  on  two  key  opti¬ 
mizations.  First,  we  can  dramatically  reduce  the  number  of  distinct  states  via  K- 
partitioning 4 ;  this  permits  n*  to  be  found  in  polynomial  time.  Second,  we  can 
ensure  that  the  state  transition  graph  is  acyclic  (a  useful  property  for  MDPs  also 
noted  in  other  contexts  [6])  by  bounding  the  number  of  suggestions  sent  to  each 
participant;  this  enables  us  to  find  7T*  with  simple  graph  search  algorithms  instead 
of  with  policy  iteration  or  linear  programming.  Furthermore,  this  approach  enables 
the  use  of  existing  heuristic  search  algorithms  where  an  exact  computation  remains 

4  See  Boutilier  et  al.  [8]  for  an  alternative  (though  not  guaranteed)  use  of  domain  structure 
to  reduce  the  effective  number  of  states. 
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Restrictions 

Description  of  Restrictions 

Complexity  with 
arbitrary  utility 
function 

Complexity  when 
K-partitionable 

AnyUnlimited 

Manager  may  suggest  changes  at  any  time, 
and  may  send  an  unlimited  number  of  sugges¬ 
tions  to  any  participant. 

EXPTIME-hard 

MDP  with  0{N2K) 
states 

AnyOnce 

Manager  may  suggest  changes  at  any  time, 
but  only  once  per  participant. 

PSPACE-hard 

0(N3K )  time 

Immediate 

Manager  may  suggest  changes  only  immedi¬ 
ately  after  receiving  a  response,  once  per  par¬ 
ticipant. 

PSPACE-hard 

0(N2K )  time 

Synchronous 

Same  as  “Immediate”,  but  each  participant  is 
assumed  to  respond  to  any  suggestion  before 
the  manager  receives  any  other  message. 

PSPACE-hard 

0(Nk  )  time 

Table  1 


Summary  of  theoretical  results  for  D-SEPs.  The  last  two  columns  show  the  time  complex¬ 
ity  of  finding  the  optimal  policy  for  a  D-SEP  with  N  participants.  In  general,  this  problem 
is  EXPTIME-hard  but  if  the  utility  function  is  K-partitionable  then  the  problem  is  polyno¬ 
mial  time  in  N.  (An  MDP  can  be  solved  in  time  guaranteed  to  be  polynomial  in  the  number 
of  states,  though  the  polynomial  has  high  degree).  Adding  restrictions  on  how  often  the 
manager  may  send  suggestions  makes  the  problem  even  more  tractable.  Note  that  the  size 
of  the  optimal  policy  is  finite  and  must  be  computed  only  once,  even  though  the  execution 
of  a  SEP  may  be  infinite  (e.g.,  with  “AnyUnlimited”). 

infeasible.  Consequently,  with  appropriate  restrictions  many  useful  D-SEPs  can  be 
efficiently  solved  in  polynomial  time. 


5.4  Explanation  Generation  for  D-SEPs 

As  with  L-SEPs,  we  would  like  to  be  able  to  automatically  generate  explanations 
for  the  manager’s  interventions.  Below  we  briefly  consider  this  problem  in  the  con¬ 
text  of  D-SEPs. 

Compared  to  L-SEPs,  it  is  more  difficult  for  a  D-SEP  to  single  out  specific  terms 
that  are  responsible  for  a  manager’s  suggestion,  because  every  term  contributes  to 
the  process  utility  to  some  extent,  either  positively  or  negatively.  Note,  though,  that 
if  the  manager  decides  to  make  a  suggestion,  then  the  expected  improvement  must 
outweigh  the  certain  cost  of  this  action.  Thus,  for  non-zero  costs,  there  must  be 
a  significant  difference  in  the  utility  of  the  state  where  the  manager  requested  a 
switch  ( Ssw )  vs.  where  the  manager  did  not  (So). 

We  seek  to  identify  the  terms  that  explain  most  of  this  difference.  In  particular, 
given  a  n-term  utility  function 
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u(s)  =  Ui(s)  +  ...  +  un(s) 


we  define  the  change  5U  in  each  utility  term  as 


Su  =  u(Ssw )  -  u(Sq). 

We  wish  to  identify  a  set  E  C  {ui, ..un}  such  that: 

P[U(Ssu,)  -  U(So)] 

u£E 

i.e.,  so  that  the  terms  in  E  explain  at  least  j3  of  the  change.  Note  that,  if  we  can 
compute  the  optimal  policy  in  polynomial  time,  then  we  can  also  compute  each  5U 
in  polynomial  time. 

When  generating  an  explanation,  we  are  primarily  interested  in  terms  indicating 
that  a  switch  is  beneficial,  i.e.,  where  Su  >  o.  If  we  only  consider  such  terms,  then  a 
greedy  algorithm  suffices  to  identify  the  explanation  E  of  guaranteed  minimal  size: 
set  E  to  0,  then  incrementally  add  to  E  the  term  with  the  largest  8U  until  E  explains 
at  least  (3  of  the  total  change.  If  we  wish  to  consider  utility  terms  with  both  positive 
and  negative  changes,  then  this  problem  becomes  more  challenging  (cf.,  Klein  and 
Shortliffe  [29]). 


5.5  Discussion 

Compared  to  L-SEPs,  the  primary  advantages  of  D-SEPs  are  their  ability  to  bal¬ 
ance  the  utility  of  the  process’s  goals  vs.  the  cost  of  additional  communication  with 
the  participants,  and  their  graceful  degradation  when  goals  cannot  be  completely 
satisfied.  On  the  other  hand,  the  need  to  determine  suitable  utilities  and  proba¬ 
bilities  is  an  inherent  drawback  of  any  decision-theoretic  framework.  Below  we 
consider  techniques  to  approximate  these  parameters. 

First,  the  7r*  for  a  D-SEP  depends  upon  the  relative  value  of  positive  utilities  (e.g., 
having  a  well-balanced  potluck)  vs.  negative  utilities  (e.g.,  the  cost  of  making  a  sug¬ 
gestion).  Our  discussion  above  exhibited  a  number  of  simple  but  reasonable  utility 
functions.  In  practice,  we  expect  that  D-SEPs  will  provide  default  utility  functions 
based  on  their  functionality,  but  would  allow  users  to  modify  these  functions  by 
adjusting  parameters  or  by  answering  a  series  of  utility  elicitation  questions  [7]. 

Second,  D-SEPs  also  require  probabilistic  information  about  how  participants  are 
likely  to  respond  to  original  requests  and  suggestions.  This  information  can  be  de¬ 
termined  in  a  number  of  ways: 
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•  User-provided:  The  process  originator  may  be  able  to  provide  reliable  esti¬ 
mates  of  what  responses  are  likely,  based  on  some  outside  information  or  past 
experience. 

•  History-based:  Alternatively,  the  system  itself  can  estimate  probabilities  by 
examining  the  history  of  past  processes. 

•  Dynamically-adjusted:  Instead  of  or  in  addition  to  the  above  methods,  the 
system  could  dynamically  adjust  its  probability  estimates  based  on  the  actual 
responses  received.  If  the  number  of  participants  is  large  relative  to  the  number 
of  choices,  then  the  system  should  be  able  to  stabilize  its  probability  estimates 
well  before  the  majority  of  responses  are  received. 

Thus,  although  the  need  to  provide  utility  and  probability  estimates  is  a  drawback 
of  D-SEPs  compared  to  L-SEPs,  simple  techniques  can  produce  reasonable  ap¬ 
proximations  for  both.  In  practice,  the  choice  of  whether  to  use  a  D-SEP  or  L- 
SEP  will  depend  on  the  target  usage  and  the  feasibility  of  parameter  estimation. 
In  our  implementation,  we  allow  the  originator  to  make  this  choice.  For  D-SEPs, 
we  currently  elicit  some  very  basic  utility  information  from  the  originator  (e.g., 
see  Figure  4),  and  use  some  probabilities  provided  by  the  SEP  author  for  expected 
participant  behavior.  Extending  our  implementation  to  support  history-based  and 
dynamically-adjusted  probabilities  is  future  work. 


6  Implementation  and  Usability 


We  have  implemented  a  complete  semantic  email  system  and  deployed  it  in  several 
applications.  In  doing  so,  we  faced  several  challenges.  This  section  describes  the 
desiderata  for  a  usable  semantic  email  system,  highlights  the  challenges  to  achiev¬ 
ing  these  desiderata,  and  discusses  our  particular  implementation  choices. 


6. 1  Desiderata 

To  be  successful,  we  argue  that  any  semantic  email  system  (both  SEP-based  and 
otherwise)  should  fulfill  the  following  desiderata: 


•  Instant  Gratification:  Most  importantly,  semantic  email  must  provide  an  im¬ 
mediate,  tangible  benefit  to  users.  Users  must  not  be  expected  to  annotate  out¬ 
going  or  incoming  mail  with  semantic  content  for  some  vague  future  benefit. 
Instead,  a  semantic  email  system  must  provide  users  with  existing  services  that 
yield  immediately  obvious  benefits.  In  fact,  the  notion  of  instant  gratification 
is  key  to  getting  people  to  invest  in  structuring  their  data,  and  has  been  the 
motivation  behind  our  MANGROVE  semantic  web  system  [38]. 
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Fig.  3.  The  creation  of  a  semantic  email  process  (SEP).  Initially,  an  “Author”  authors  a 
SEP  template  and  this  template  is  used  to  generate  an  associated  web  form.  Later,  this 
web  form  is  used  by  the  “Originator”  to  instantiate  the  template.  Typically,  a  template  is 
authored  once  and  then  instantiated  many  times. 


•  Gradual  Adoption:  At  first,  semantic  email  will  be  initiated  by  only  a  small 
number  of  “early  adopters.”  If  semantic  email  could  be  profitably  exchanged 
only  among  these  users,  it  would  have  very  limited  applicability.  Thus,  to  suc¬ 
ceed,  semantic  email  must  be  usable  even  when  some  or  all  of  the  participants 
have  no  experience  with  or  software  installed  for  it. 

•  Ease  of  use:  Semantic  email  must  be  simple  enough  for  a  non-technical  per¬ 
son  to  use.  It  should  not  expect  such  users  to  understand  RDF,  disrupt  nor¬ 
mal  email  processing,  or  require  email  senders  or  recipients  to  use  a  particular 
email  client. 


Below  we  elaborate  on  the  challenges  in  implementing  a  system  that  achieves  these 
goals. 


6.2  Process  Creation  and  Execution 


Translating  SEP  theory  to  real  problems:  Applying  our  SEP  theory  to  real  prob¬ 
lems  requires  enabling  an  originator  to  easily  create  an  L-SEP  or  D-SEP  model 
that  corresponds  to  his  goals.  One  option  is  to  build  a  GUI  tool  that  guides  the  orig¬ 
inator  through  constructing  the  appropriate  choices,  messages,  and  constraints  or 
utilities  for  the  process.  Practically,  however,  a  tool  that  is  general  enough  to  build 
an  arbitrary  process  is  likely  to  be  too  complex  for  untrained  users. 

Instead,  our  system  is  based  on  the  construction  of  reusable  templates  for  specific 
classes  of  SEPs.  Figure  3  demonstrates  this  approach.  Initially,  someone  who  is  as¬ 
sumed  to  have  some  knowledge  of  RDF  and  semantic  email  authors  a  new  template 
using  an  editor  (most  likely  by  modifying  an  existing  template).  We  call  this  per¬ 
son  the  SEP  author.  The  template  is  written  in  OWL  [57]  based  on  a  SEP  ontology 
that  describes  the  possible  queries,  constraints,  and  messages  for  a  process.  For  in¬ 
stance,  the  “balanced  potluck”  template  defines  the  general  balance  constraints  for 
the  process,  but  has  placeholders  for  parameters  such  as  the  participants’  addresses, 
the  specific  choices  to  offer,  and  how  much  imbalance  to  permit. 

To  enable  an  originator  to  provide  these  parameters  later,  we  associate  with  each 
template  a  simple  web  form  that  prompts  the  originator  for  each  parameter.  For  in- 
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File  Edit  View  Favorites  Tools  Help 

sr 

•  Who  should  receive  email  about  this  process? 
uw-dto@cs.washington.edu,  faculty@cs.washington.edu 

•  The  following  greeting  will  be  sent  on  your  behalf.  You  can  edit  it  you  wish. 

jj9| 

You  have  been  invited  to  the  potluck  described  below.  ^ 

Please  use  the  form  below  to  indicate  what  you  are  bringing. 
iTo  ensure  that  our  meal  selection  is  balanced,  you  may  be 
asked  to  change  your  selection.  v 

•  Enter  details  about  the  event: 

D e s cription: |  D  atab  as  e  An  n  u  al  Potl u ck  1  (Optional ) 

Location:  Dan  Suciu's  house,  5320  Northwest  Way  (Optional) 

Start  dine  Oct  v  5  1, 1 2003  v  at:5  v  [  00  v  p.m.  v  PDT  - 

•  Enter  the  choices  for  recipients  to  choose  from,  separated  by  commas. 

!  Not  Coming,  Appetizer,  Entree,  Dessert 

II 

•  This  process  will  count  the  number  of  responses  for  each  choice  given  above.  To  automatically 
"balance"  the  results,  specify  any  desired  restrictions  to  enforce  on  these  responses:  (Explain  this) 

Minimum  count  of  each  choice:  (enter  a  positive  integer  or  leave  blank) 

Maximum  count  of  each  choice:  1  Renter  a  positive  integer  or  leave  blank) 

Maximum  discrepancy  in  counts:  \z j(enter  a  positive  integer  or  leave  blank) 

Choices  to  exclude  from  these  restrictions:  Not  Coming  (comma- separated  list) 

•  How  should  these  restrictions  be  enforced?  (Explain  this) 

®  Enforce  strictly,  so  that  the  collection  result  is  guaranteed  to  be  balanced. 

O  Enforce  flexibly,  to  give  responders  maximum  choice  so  long  as  balance  is  still  possible. 

.  Tradeoff-based:  accept  all  responses,  but  request  a  change  from  someone  if  the  imbalance 
in  any  restriction  is  projected  to  be  more  than  1 

|  Submit  |  V!, 

Fig.  4.  A  web  form  used  to  initiate  a  “balanced  collection”  process,  such  as  our  balanced 
potluck  example.  For  convenience,  clicking  submit  converts  the  form  to  text  and  sends  the 
result  to  the  server  and  a  copy  to  the  originator.  The  originator  may  later  initiate  a  similar 
process  by  editing  this  copy  and  mailing  it  directly  to  the  server. 

stance,  Figure  4  shows  such  a  form  for  the  balanced  potluck.  Note  that  the  bottom 
of  this  form  allows  users  to  choose  between  executing  an  L-SEP  (the  “strictly”  and 
“flexibly”  options)  or  a  D-SEP  (the  “tradeoff-based”  option).  In  addition,  origi¬ 
nators  may  specify  either  individuals  or  mailing  lists  as  participants;  for  the  latter 
case,  the  form  also  asks  the  originator  for  an  estimate  of  the  total  number  of  people 
that  will  respond  (not  shown  in  Figure  4). 

Our  implementation  provides  a  simple  tool  that  can  automatically  generate  such 
web  forms  from  some  additional  OWL  information  in  the  template.  This  same  tool 
could  also  be  used  to  generate  a  service  description  for  the  template,  e.g.,  in  WSDL 
or  OWL-S  [2].  Then,  a  program  could  also  serve  as  an  originator  by  utilizing  the 
service  description  and  template  to  automatically  invoke  the  process  directly. 

An  untrained  originator  finds  a  SEP  from  a  public  library  of  SEP  templates  and 
instantiates  the  template  by  filling  out  the  corresponding  web  form,  yielding  a  SEP 
declaration  (also  in  OWL).  The  originator  then  invokes  the  process  by  forwarding 
this  declaration  to  the  manager.  Given  the  formal  declaration,  the  manager  then 
executes  the  process,  using  appropriate  L-SEP  and  D-SEP  algorithms  to  decide 
how  to  direct  the  process  via  appropriate  message  rejections  and  suggestions 


25 


Facilitating  responses:  Another  key  challenge  is  enabling  participants  to  respond 
to  messages  in  a  way  that  is  convenient  but  that  can  be  automatically  interpreted  by 
the  manager.  A  number  of  different  solutions  are  possible: 

•  Client  software:  We  could  provide  a  custom  email  client  that  would  present 
the  participant  with  an  interface  for  constructing  legal  responses,  or  automati¬ 
cally  respond  to  messages  it  knows  how  to  handle  (e.g.,  “Decline  all  invitations 
for  Friday  evenings”).  This  client-based  approach,  however,  requires  all  partic¬ 
ipants  in  a  process  to  install  additional  software  (conflicting  with  our  gradual 
adoption  goal)  and  is  complicated  by  the  variety  of  mail  clients  currently  in 
use. 

•  Information  extraction:  We  could  allow  participants  to  respond  in  a  natural 
language  (e.g.,  “Fll  bring  a  dessert”).  We  could  then  use  wrappers  or  infor¬ 
mation  extraction  techniques  to  attempt  to  convert  this  response  to  one  of  the 
offered  choices.  This  approach  is  promising  but  risks  having  the  wrapper  fail 
to  extract  the  correct  information. 

•  Email  or  web  forms:  We  could  provide  participants  with  a  text-encoded  form 
to  fill  out,  or  we  could  send  them  a  link  to  a  suitable  web-based  form  to  use  for 
their  response.  Embedded  HTML  forms  are  also  attractive,  but  unfortunately 
are  not  handled  uniformly  by  existing  email  clients. 

While  web  forms  have  some  advantages,  we  chose  to  use  email  text  forms  instead 
because  we  feel  they  fit  more  naturally  with  how  people  typically  handle  incom¬ 
ing  messages.  In  addition,  text  forms  offer  a  simple  solution  that  works  for  any 
participant.  Participants  respond  by  replying  to  the  process  message  and  editing 
the  original  form.  If  the  manager  sends  a  rejection  or  suggestion  to  a  participant, 
the  message  includes  an  explanation  of  the  intervention  along  with  a  copy  of  the 
original  form  so  that  the  participant  can  modify  their  response. 

Our  earlier  discussion  generally  assumed  that  participants  would  send  a  single 
acceptable  response.  However,  our  implementation  does  permit  participants  to 
“change  their  mind”  by  sending  additional  responses.  For  the  logical  model,  this 
response  is  accepted  if  changing  the  participant’s  original  response  to  the  new 
value  still  permits  the  constraints  to  be  satisfied  (or  if  the  response  must  always 
be  accepted,  e.g.,  for  Not-Coming).  For  the  decision-theoretic  model,  the  new 
response  is  always  accepted  but  may  lead  to  a  change  suggestion  based  on  the 
modified  state  of  the  process. 

Manager  deployment:  Potentially,  the  manager  could  be  a  program  run  on  the 
originator’s  personal  computer,  perhaps  as  part  of  his  mail  client.  This  permits  an 
easy  transition  between  authoring  traditional  mails  and  invoking  SEPs,  and  can  also 
benefit  from  direct  access  to  the  originator’s  personal  information  (e.g.,  calendar, 
contacts).  However,  as  with  providing  client  software  for  participants,  this  approach 
requires  software  installation  and  must  deal  with  the  wide  variety  of  existing  mail 
clients. 

Our  implementation  instead  deploys  the  manager  as  a  shared  server.  The  server 
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SEP  name 

Procedural  approach 
(number  of  lines) 

Declarative  approach 
(  number  of  lines) 

Size  Reduction 

for  Declarative 

Balanced  Potluck 

1680 

170 

90% 

First-come,  First-served 

536 

99 

82% 

Meeting  Coordination 

743 

82 

89% 

Request  Approval 

1058 

109 

90% 

Auction 

503 

98 

81% 

Table  2 


Comparison  of  the  size  of  a  SEP  specification  in  our  original  procedural  prototype  [17] 
(using  Java/HTML)  vs.  in  the  declarative  format  described  in  this  paper  (using  RDF). 
Overall,  the  declarative  approach  is  about  80-90%  more  concise.  These  values  include  the 
HTML/RDF  needed  for  acquiring  par  ameters  from  the  originator. 

receives  invocations  from  the  originator  and  sends  out  an  initial  message  to  the  par¬ 
ticipants.  Participants  reply  via  mail  directly  to  the  server,  rather  than  to  the  origina¬ 
tor,  and  the  originator  receives  status  and  summary  messages  from  the  server  when 
appropriate.  The  originator  can  query  or  alter  the  process  via  additional  messages 
or  a  web  interface. 

Discussion:  Our  server-based  approach  is  easy  to  implement  and  meets  our  gradual 
adoption  and  ease-of-use  goals  since  it  requires  no  software  installation,  works 
for  all  email  clients,  and  does  not  require  users  (as  originators)  to  read  or  write 
RDF.  In  addition,  this  method  supports  our  instant  gratification  goal  by  providing 
untrained  users  with  existing,  useful  SEPs  that  can  be  immediately  invoked  and 
yield  a  tangible  output  (in  the  form  of  messages  sent  and  processed  on  the  users’ 
behalf).  Finally,  we  believe  that  divorcing  the  processing  of  semantic  email  (in 
the  server)  from  the  standard  email  flow  (in  the  client)  will  facilitate  adoption  by 
ameliorating  user  concerns  about  privacy  5  and  about  placing  potentially  buggy 
code  in  their  email  client. 

In  addition,  specifying  SEP  templates  and  declarations  in  OWL  has  a  number  of 
advantages.  First,  unlike  the  original  version  of  semantic  email  [17]  (which  used 
process-specific  procedures),  a  SEP  is  described  entirely  by  its  OWL  declaration. 
This  greatly  simplifies  the  deployment  of  a  new  SEP,  both  because  no  program¬ 
ming  is  required  and  because  authors  need  not  run  their  own  server  (since  shared 
servers  can  accept  and  execute  OWL  declarations  from  anyone,  something  they  are 
unlikely  to  do  for  arbitrary  code).  In  addition,  these  declarations  are  much  simpler 
and  more  concise  than  corresponding  specifications  written  in  a  procedural  lan¬ 
guage  (see  Table  2).  Furthermore,  authoring  SEPs  in  OWL  enables  the  use  of  a 
variety  of  automated  tools  to  ensure  that  a  SEP  declaration  is  valid.  Finally,  OWL 


5  Only  semantic  email  goes  through  the  server,  personal  email  is  untouched.  Of  course, 
when  the  semantic  email  also  contains  sensitive  information,  the  security  of  the  server 
becomes  significant. 
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®  Database  potluck  --  please  RSVP  -  Message  (HTML) 

□08 

File  Edit  View  Insert  Format  Tools  Actions  Help 

From:  Semweb  Project  [semweb(®cs.  Washington,  edu] 

Type  a  que 

stion  For  help  .  ▼ 

rap@cs.washmgton.edu  sends  the  folio wmg  message: 

You  have  been  invited  to  the  potluck  described  below. 

Please  use  the  form  below  to  indicate  what  you  are  bringing.  To  ensure 
that  our  meal  selection  ^s  balanced,  you  may  be  asked  to  change  your  selection. 

Description:  Database  Annual  Potluck 

Location:  Dan  Suciu's  house:  5320  Northwest  Way 

Date  and  Time:  Sunday,  October  5,  2003  5:00:00  PM  PDT 

(fOBiiiigmg  [  1  (enter  a  number  1-4  between  the  brackets) 

1.  Not  Coining 

2.  Appetizer 

3.  Entree 

4.  Dessert 

****  The  information  below  is  to  assist  with  automated  processing  ****** 
of  your  answers.  Please  mclude  it  in  your  response  without  modification. 

SELECT  Tyourtring,  ?Briiigiiig 

WHERE  (<uw:processID379>,  <rtlfcal:  attendee>,  ?xl), 

(?xl,  <rdfeal:  caLA(ldress>,  ?youstring), 

(?xl,  <uw:biinging>,  ?Biinging) 

USING  rdfcal  FOR  -  littp  www.w3.oi  g  2002  12  cnl ical-  > 
nw  FOR  http:  ■vwww.cs.wasliington  edu.  resear  ch  semweb  vocab#vl  0:> 


Fig.  5.  A  message  sent  to  participants  in  a  “balanced  potluck”  process.  The  bold  text  in  the 
middle  is  a  form  used  for  human  recipients  to  respond,  while  the  bold  text  at  the  bottom  is 
a  RDQL  query  that  maps  their  textual  response  to  RDF. 

specifications  could  enable  future  work  that  automatically  composes  several  SEPs 
to  accomplish  more  complex  goals. 

6.3  Human/Machine  Interoperability 

The  previous  section  highlighted  how  semantic  email  messages  can  be  handled  by 
either  a  human  or  by  a  program  operating  on  their  behalf.  Thus,  an  important  re¬ 
quirement  is  that  every  message  must  contain  both  a  human-understandable  portion 
(e.g.,  “You’re  invited  to  the  potluck  on  Oct  5...”)  and  a  corresponding  machine- 
understandable  portion.  For  messages  sent  to  a  participant,  this  approach  supports 
gradual  adoption  by  permitting  the  originator  to  send  the  same  message  to  all  par¬ 
ticipants  without  any  knowledge  of  their  capabilities.  For  responses,  a  machine- 
understandable  portion  enables  the  manager  to  evaluate  the  message  against  the 
process  constraints/utilities  and  take  further  action.  The  human-readable  compo¬ 
nent  provides  a  simple  record  of  the  response  if  needed  for  later  review. 

In  our  implementation,  we  meet  this  interoperability  requirement  with  a  combina¬ 
tion  of  techniques.  For  responses,  a  human  can  fill  out  the  included  text  form  (see 
Figure  5),  which  is  then  converted  into  RDF  at  the  server  with  a  simple  mapping 
from  each  field  to  an  unbound  variable  in  a  RDQF  query  associated  with  the  mes- 
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sage.  Alternatively,  a  machine  can  respond  to  the  message  simply  by  answering  the 
query  in  RDF,  then  applying  the  inverse  mapping  in  order  to  correctly  fill  out  the 
human-readable  text  form. 

For  messages  to  the  participants,  the  challenge  is  to  enable  the  manager  to  construct 
these  textual  and  RDF/RDQL  portions  directly  from  the  SEP  declaration.  Here 
there  is  a  tension  between  the  amount  of  RDF  content  that  must  be  provided  by  the 
SEP  author  (in  the  template)  vs.  that  provided  by  the  SEP  originator  (when  instan¬ 
tiating  the  template).  Very  specific  SEP  templates  (e.g.,  to  balance  N  people  among 
appetizer,  entree,  and  dessert  choices)  are  the  easiest  to  instantiate,  because  the  au¬ 
thor  can  specify  the  RDF  terms  needed  in  advance.  General  SEP  templates  (e.g.,  to 
balance  N  people  among  K  arbitrary  choices)  are  much  more  reusable,  but  require 
substantially  more  work  to  instantiate  (and  may  require  understanding  RDF).  Al¬ 
ternatively,  authors  may  provide  very  general  templates  but  make  the  specification 
of  RDF  terms  for  the  choices  optional;  this  enables  easy  template  reuse  but  fails  to 
provide  semantic  content  for  automated  processing  by  the  participants. 

In  our  current  system,  we  offer  both  highly  specialized  SEPs  (e.g.,  for  meeting 
scheduling)  and  more  general  SEPs  (e.g.,  to  give  away  some  type  of  item).  En¬ 
abling  originators  to  easily  customize  general  SEPs  with  precise  semantic  terms, 
perhaps  from  a  set  of  offered  ontologies,  is  an  important  area  of  future  work. 

6.4  Integrating  with  Non-Semantic  Messages 

Despite  the  advantages  of  semantic  email,  we  do  not  want  to  create  a  strict  di¬ 
chotomy  in  our  email  habitat.  In  our  potluck  example,  suppose  that  one  of  the 
participants  wants  to  know  whether  there  is  organized  transportation  to  the  potluck 
(and  this  information  affects  his  decision  on  what  to  bring).  What  should  he  do? 
Compose  a  separate  non-semantic  email  to  the  originator  and  respond  to  the  se¬ 
mantic  one  only  later?  A  better  (and  easier  to  use)  solution  would  be  to  treat  both 
kinds  of  emails  uniformly,  and  enable  the  participant  to  ask  the  question  in  reply¬ 
ing  to  the  semantic  email,  ultimately  providing  the  semantic  response  later  on  in 
the  thread. 

Our  implementation  supports  this  behavior  by  supplying  an  additional  Remarks 
field  in  each  response  form,  where  a  participant  may  include  a  question  or  comment 
to  be  forwarded  to  the  originator.  For  a  question,  the  originator  can  reply,  enabling 
the  participant  to  respond  to  the  original  semantic  question  with  the  included  form 
or  pose  another  question. 

6.5  Experience 

Our  semantic  email  system  is  deployed  and  may  be  freely  used  by  anyone  with¬ 
out  any  software  installation;  the  source  code  for  deploying  other  instances  of  the 
server  is  also  available.  So  far  we  have  developed  simple  processes  for  functions 
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like  collecting  RSVPs  (i.e.,  confirming  or  declining  an  invitation),  giving  tickets 
away,  scheduling  meetings,  and  balancing  a  potluck.  Our  system  uses  standard  on¬ 
tologies  where  possible  (e.g.,  RDF  Calendar  [56]),  augmented  as  needed  with  a 
local  semantic  email  schema. 

Despite  very  limited  publicity,  our  semantic  email  server  has  seen  growing  interest 
over  the  short  time  that  it  has  been  available.  For  instance,  a  DARPA  working  group 
has  adopted  semantic  email  for  all  of  its  meeting  scheduling  and  RSVP  needs,  stu¬ 
dents  have  used  semantic  email  to  schedule  seminars  and  Ph.  D.  exams,  and  seman¬ 
tic  email  has  been  used  to  organize  our  annual  database  group  and  departmental¬ 
wide  potlucks.  Furthermore,  a  number  of  other  institutions  have  expressed  interest 
in  deploying  copies  of  semantic  email  locally  at  their  sites.  These  are  merely  anec¬ 
dotes  but  lend  credence  to  our  claim  that  semantic  email  is  both  useful  and  practical. 

Our  semantic  email  system  is  integrated  within  our  larger  Mangrove  [38]  se¬ 
mantic  web  system.  This  provides  us  with  an  RDF-based  infrastructure  for  man¬ 
aging  email  data  and  integrating  with  web-based  data  sources  and  services.  For  in¬ 
stance,  the  Mangrove  web  calendar  accepts  event  information  via  email  or  from 
a  web  page.  In  addition,  MANGROVE  provides  semantic  email  with  an  RDF  data 
source  about  courses,  people,  etc.  that  could  be  used  to  support  the  prediction  of 
likely  responses  by  the  manager  discussed  in  Section  2.  Likewise,  a  semantic  email 
client  could  utilize  data  from  MANGROVE  to  answer  common  questions.  When 
previously  unknown  questions  are  answered  manually  by  the  user,  these  responses 
could  be  stored  for  future  use,  thus  enabling  the  automatic  acquisition  of  semantic 
knowledge  over  time.  Future  work  will  consider  additional  ways  to  synergistically 
leverage  data  from  both  the  web  and  email  worlds  in  MANGROVE. 


7  Related  Work 


Information  Lens  [36]  used  forms  to  enable  a  user  to  generate  a  single  email  mes¬ 
sage  with  semi- structured  content  that  might  assist  recipients  with  filtering  and  pri¬ 
oritizing  that  message.  Our  SEPs  generalize  this  earlier  work  by  enabling  users  to 
create  an  email  process  consisting  of  a  set  of  interrelated  messages,  and  by  extend¬ 
ing  Information  Lens’s  rule -based  message  processing  to  support  more  complex 
constraint  and  utility  reasoning  based  on  information  from  the  entire  set  of  mes¬ 
sages.  Consequently,  SEPs  support  a  much  broader  range  of  possible  applications. 
More  recently,  Kalyanpur  et  al.  [27]  proposed  having  users  semantically  annotate 
messages  to  improve  mail  search,  sorting,  and  filtering.  This  approach  can  poten¬ 
tially  result  in  rich  semantic  content,  but  requires  users  to  invest  significant  anno¬ 
tation  effort  for  some  potential  future  benefit  (e.g.,  in  improved  searching  for  an 
old  email)  or  primarily  for  the  benefit  of  the  recipient.  SEPs  instead  generate  both 
the  semantic  content  and  the  text  of  the  email  message  directly  from  simple  forms, 
and  provide  instant  gratification  by  immediately  utilizing  this  content  for  simple 


30 


but  time-saving  email  processes. 


Our  vision  for  semantic  email  was  initially  described  in  Etzioni  et  al.  [17]  and  Mc¬ 
Dowell  et  al.  [39].  Possible  uses  of  semantic  email  are  similar  to  those  of  some 
existing  semantic  web  systems  (e.g.,  [47,30,42],  cf.,  RDF  Calendar  group  discus¬ 
sions  [56]).  The  key  differentiating  aspects  of  our  work  are  its  generality  to  many 
different  tasks,  its  ability  to  interoperate  freely  with  naive  participants,  and  its  poly¬ 
nomial  time  reasoning  for  recommending  interventions.  For  instance,  Real  [47] 
uses  messages  between  participants  to  agree  upon  meeting  times  and  Mcllraith 
et  al.  [42]  describe  an  agent  that  makes  travel  arrangements  by  invoking  various 
web  services  (which  could  be  modeled  as  participants  in  a  SEP).  These  systems, 
however,  enable  full  interaction  only  between  two  parties  that  are  both  executing 
domain-specific  software.  For  instance,  though  Real  provides  a  web  interface  to 
let  anyone  schedule  an  appointment  with  an  installed  Real  user,  an  Real  user  can¬ 
not  use  the  system  to  request  an  appointment  with  a  non-“Rcal-enabled”  person. 
Fikewise,  Mcllraith  et  al.’s  agent  is  designed  only  to  communicate  with  specific 
web  services,  not  with  humans  (such  as  human  travel  agents)  that  could  offer  the 
same  functionality.  Our  system  instead  permits  processes  to  include  any  user,  re¬ 
gardless  of  their  capabilities.  An  additional,  though  less  critical,  distinction  is  our 
use  of  email  instead  of  HTTP  or  a  custom  protocol  (cf.,  Everyware  [19]).  Email 
provides  a  convenient  transport  mechanism  because  the  vast  majority  of  users  al¬ 
ready  have  well-known  addresses  (no  additional  directories  are  needed),  messages 
can  be  sent  regardless  of  whether  the  recipient  has  performed  any  configuration, 
and  existing  email  clients  provide  a  useful  record  of  messages  exchanged.  Finally, 
our  framework  enables  the  automated  pursuit  of  a  wide  variety  of  goals  through 
reasoning  in  guaranteed  polynomial  time,  a  result  not  provided  by  the  other  sys¬ 
tems  discussed  above.  The  combination  of  these  factors  makes  semantic  email  a 
lightweight,  general  approach  for  automating  many  tasks  that  would  be  impractical 
with  other  systems. 

Recent  work  on  the  Inference  Web  [41]  has  focused  on  the  need  to  explain  a  Se¬ 
mantic  Web  system’s  conclusions  in  terms  of  base  data  and  reasoning  procedures. 
In  contrast,  we  deal  with  explaining  the  SEP’s  actions  in  terms  of  existing  re¬ 
sponses  and  the  expected  impact  on  the  constraints.  In  this  sense  our  work  is  sim¬ 
ilar  to  prior  research  that  sought  to  explain  decision-theoretic  advice  (cf.,  Horvitz 
et  al.  [21]).  For  instance,  Klein  and  Shortliffe  [29]  describe  the  VIRTUS  system 
that  can  present  users  with  an  explanation  for  why  one  action  is  provided  over  an¬ 
other.  Note  that  this  work  focuses  on  explaining  the  relative  impact  of  multiple 
factors  on  the  choice  of  some  action,  whereas  we  seek  the  simplest  possible  reason 
why  some  action  could  not  be  chosen  (i.e.,  accepted).  Other  relevant  work  includes 
Druzdzel  [16],  which  addresses  the  problem  of  translating  uncertain  reasoning  into 
qualitative  verbal  explanations. 

For  constraint  satisfaction  problems  (CSPs),  a  nogood  [51]  is  a  reason  that  no  cur¬ 
rent  variable  assignment  can  satisfy  all  constraints.  In  contrast,  our  explanation 
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for  a  PossiblyConstraint  is  a  reason  that  no  future  assignment  can  satisfy 
the  constraints,  given  the  set  of  possible  future  responses.  Potentially,  our  problem 
could  be  reduced  to  nogood  calculation,  though  a  direct  conversion  would  produce 
a  problem  that  might  take  time  that  is  exponential  in  N,  the  number  of  participants. 
However,  for  bounded  constraints,  we  could  create  a  CSP  with  variables  based 
on  the  aggregates  of  the  responses,  rather  than  their  specific  values,  as  described  in 
Section  3.  Using  this  simpler  CSP,  we  could  then  exploit  existing,  efficient  nogood- 
based  solvers  (e.g.,  [25,28,24])  to  find  candidate  explanations  in  time  polynomial 
in  N.  Note  though  that  most  applications  of  nogoods  have  focused  on  their  use  for 
developing  improved  constraint  solving  algorithms  [51,28]  or  for  debugging  con¬ 
straint  programs  [46],  rather  than  on  creating  explanations  for  average  users.  One 
exception  is  Jussien  and  Ouis  [26],  who  describe  how  to  generate  user-friendly 
nogood  explanations,  though  they  require  that  a  designer  explicitly  model  a  user’s 
perception  of  the  problem  as  nodes  in  some  constraint  hierarchy. 


8  Conclusions 

This  paper  generalizes  the  original  vision  of  the  semantic  web  to  also  encompass 
email.  We  have  introduced  a  paradigm  for  semantic  email  and  described  a  broad 
class  of  semantic  email  processes.  These  automated  processes  offer  tangible  pro¬ 
ductivity  gains  on  email-mediated  tasks  that  are  currently  performed  manually  in  a 
tedious,  time-consuming,  and  error-prone  manner.  Moreover,  semantic  email  opens 
the  way  to  scaling  similar  tasks  to  large  numbers  of  people  in  a  manner  that  is  infea¬ 
sible  today.  For  example,  large  organizations  could  carry  out  surveys,  auctions,  and 
complex  meeting  coordination  via  semantic  email  with  guarantees  on  the  behavior 
of  these  processes. 

Our  technical  contributions  are  as  follows.  We  presented  a  formalization  that  teases 
out  the  issues  involved,  and  used  this  formalization  to  explore  several  central  infer¬ 
ence  questions.  We  then  defined  and  explored  two  useful  models  for  specifying  the 
goals  of  a  process  and  formalizing  when  and  how  the  manager  of  the  process  should 
intervene.  For  our  logical  model  we  showed  how  the  problem  of  deciding  whether 
a  response  was  ultimately  acceptable  relative  to  the  constraints  could  be  solved  in 
polynomial  time  for  bounded  constraints.  With  our  decision-theoretic  model  we 
addressed  several  shortcomings  of  the  logical  model  and  demonstrated  how  appro¬ 
priate  restrictions  could  enable  the  optimal  policy  for  this  model  to  be  computed 
in  polynomial  time.  In  both  cases  we  identified  restrictions  that  greatly  improved 
the  tractability  of  the  key  reasoning  problems  while  still  enabling  a  large  number  of 
useful  processes  to  be  represented.  In  addition,  we  described  how  to  automatically 
generate  explanations  for  the  manager’s  interventions  and  identified  cases  where 
these  explanations  can  be  computed  in  polynomial  time.  Finally,  we  described  our 
publicly  available  semantic  email  system  and  how  it  satisfies  the  implementation 
desiderata  of  instant  gratification,  gradual  adoption,  and  ease  of  use. 
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There  are  a  number  of  interesting  directions  for  future  work.  First,  we  want  to  con¬ 
sider  interactions  between  semantic  email  and  other  semantic  web  applications  to 
support  more  sophisticated  reasoning  techniques  (e.g.,  check  calendars  and  other 
resources  to  help  constrain  the  number  of  messages  and  responses  from  some  par¬ 
ticipants).  We  also  plan  to  incorporate  our  recent  work  on  schema  and  ontology 
mapping  [14]  to  support  more  flexibility  in  responding  to  a  semantic  email  mes¬ 
sage.  In  addition,  our  deployed  system  for  semantic  email  offers  the  potential  for  a 
number  of  interesting  user  studies.  For  instance,  it  would  be  interesting  to  examine 
how  originators  make  use  of  SEPs  and  which  types  are  the  most  popular,  the  impact 
SEPs  have  on  the  efficiency  of  tasks  compared  to  traditional  email  management, 
and  how  users  react  to  interventions.  Finally,  we  identified  specific  cases  where  our 
reasoning  is  tractable,  but  there  are  many  opportunities  for  studying  other  cases 
within  the  framework  we  provided  for  modeling  SEPs. 
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A  Proof  Sketches  for  Logical  SEPs 


This  section  provides  more  details  on  the  proofs  for  each  of  this  paper’s  theorems 
related  to  L-SEPs.  We  assume  throughout  that  an  L-SEP  A  has  N  participants,  a 
current  state  D,  and  constraints  Co,  and  that  Co  refers  to  at  most  some  constant  H 
number  of  attributes. 

A.l  Proof  of  Theorem  1 

We  first  show  that  ultimate  satisfiability  is  NP-complete  in  the  general  case.  We 
then  show  how  this  problem  can  be  solved  in  polynomial  time  when  the  constraints 
are  either  domain-bounded  or  constant-bounded. 

NP-complete  for  arbitrary  constraints:  First,  observe  that  ultimate  satisfiability 
is  in  NP  -  given  an  L-SEP  A  and  a  response  r,  we  can  guess  a  possible  outcome  of 
D  that  is  consistent  with  r,  then  verify  that  the  outcome  satisfies  the  constraints. 
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Second,  we  show  that  ultimate  satisfiability  is  NP-hard  via  a  reduction  from  3-SAT. 
Assume  we  are  given  a  boolean  formula  0  of  the  form  0  =  Lx  AL2  A...  ALm  where 
L,j  =  (wj  |  V  vji2  V  ''A3)  for  1  <  i  <  m,  and  each  w,3  equals  some  variable  xk  or 
Wk  for  1  <  k  <  n.  The  3-SAT  problem  is  to  determine  if  0  is  satisfiable  for  some 
assignment  to  the  variables  of  w. 

Given  0,  we  construct  an  L-SEP  A  where: 

•  Participants  P  =  {p0,p1,p2,  ...,pn} 

•  Data  set  D  is  a  single  table  with  one  attribute  value 

•  Responses  R  =  {nil,  ri,r2,  ...rn} 

•  Constraints  Cd  =  0,  with  nl3  substituted  for  each  Wij  where 

if  Wij  =  Xk,  then  we  set  vi3  =  [(COUNT(*)  WHERE  value  =  rk)  >  0] 
otherwise  wl3  =  xj~.  and  Vij  =  [(COUNT(*)  WHERE  value  =  rk)  =  0] 

This  construction  is  polynomial  in  the  size  of  0.  In  the  resulting  A,  there  are  n  +  1 
participants  that  may  each  respond  with  one  of  n  +  1  values. 

Given  this  constructed  A,  we  now  show  that  the  3-SAT  formula  0  is  satisfiable  iff 
an  initially  empty  D  for  A  is  ultimately  satisfiable  w.r.t.  Cd  given  response  nil. 
First,  given  an  assignment  x\,  ...,xn  that  satisfies  0,  a  final  state  of  D  that  satisfies 
CD  is  as  follows:  p0  responds  nil,  pk  responds  rk  if  xk  is  true,  otherwise  pk  responds 
nil.  This  will  set  the  corresponding  xks  in  Co  to  true,  and  since  0  is  satisfied,  Cd 
will  be  satisfied  in  the  resultant  state,  demonstrating  that  D  is  ultimately  satisfiable 
given  an  initial  response  nil.  Alternatively,  if  D  is  ultimately  satisfiable  given  ini¬ 
tial  response  nil,  we  can  take  a  final  state  of  D  that  satisfies  Cd  and  construct  an 
assignment  xi, ....  xk  that  satisfies  0  as  follows:  if  any  participant  has  responded 
with  value  rk,  then  xk  is  true;  otherwise,  xk  is  false.  Thus,  any  3-SAT  problem  with 
N  variables  can  be  solved  by  reduction  to  ultimate  satisfiability  with  +  1  partic¬ 
ipants.  Since  3-SAT  is  NP-complete  in  N,  ultimate-satisfiability  must  be  NP-hard 
in  N. 


Polynomial-time  when  constraints  are  domain-bounded :  In  this  case,  the  con¬ 
straints  refer  to  attributes  whose  domain  size  is  at  most  some  constant  L.  Since 
there  are  most  H  attributes,  there  are  thus  a  total  of  LH  possible  responses. 


We  evaluate  the  constraints  over  D' ,  a  data  set  that  distinguishes  only  representative 
states  that  are  different  with  respect  to  the  constraints.  In  particular,  all  that  matters 
for  D'  is  the  number  of  each  type  of  response  that  has  been  received  (i.e.,  aggregates 
of  the  responses).  The  number  of  possible  states  of  D'  is  thus  the  number  of  ways 
of  dividing  N  participants  among  LH  +  1  possible  responses  {LH  choices  plus  a 
“no  response”  option): 


D' 


f  N  +  LH\ 

V  lh  ) 


Q{Nlh ) 


To  determine  ultimate  satisfiability  of  D  given  r,  we  construct  a  data  set  Dr  that  is 
D  augmented  with  the  given  response  r.  We  then  iterate  over  all  possible  values  d 
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of  D'.  For  each  value,  if  d  is  inconsistent  with  Dr  (i.e.,  for  some  response  type  Ri, 
Dr  shows  more  such  responses  than  d  does),  we  discard  d.  Otherwise,  we  evaluate 
C'o  over  d  -  this  requires  time  linear  in  N  and  C'o  given  a  particular  d.  Given 
this  procedure,  D  is  ultimately  satisfiable  for  r  iff  some  d  is  consistent  with  Dr  and 
satisfies  C'o-  Each  step  requires  linear  time,  and  there  are  a  polynomial  number  of 
iterations  ( 0(NLH )),  so  the  total  time  is  polynomial  in  N  and  \C'o\. 


Polynomial-time  when  constraints  are  constant-bounded :  This  case  uses  a  sim¬ 
ilar  algorithm  as  when  the  constraints  are  domain-bounded.  However,  since  each 
attribute  may  have  a  potentially  infinite  domain,  we  must  keep  track  of  the  possible 
states  differently.  Here,  we  allow  only  COUNT  aggregations,  which  may  be  of  the 
form:  COUNT(*)  WHERE  value  =  vt  or  an  inequality  like  COUNT(*)  WHERE 
value  >  Vi. 

If  Co  is  constant-bounded,  then  there  are  most  K  constants  Vi, ...,  %\  used  in  these 
aggregations.  These  constants  divide  the  domain  of  each  attribute  into  at  most  K + 1 
regions.  Thus,  there  are  K + 1  possibilities  for  each  of  the  H  attributes  of  a  response, 
yielding  a  total  of  0(KH )  possible  responses.  As  with  the  analysis  above,  the 
number  of  possible  states  in  the  representative  data  set  D'  is  thus  0(NKH),  and  the 
time  to  evaluate  each  state  is  linear.  Since  H  and  K  are  assumed  to  be  constants, 
then  the  total  time  to  check  ultimate  satisfiability  is  polynomial  in  both  N  and  C'o  \ . 


A.2  Proof  of  Theorem  2 


For  this  theorem  we  are  given  an  L-SEP  A,  current  state  D,  and  some  Possibly- 
Constraints  Co,  and  wish  to  compute  the  acceptable  set  A  of  A.  We  consider 
the  two  cases  where  CD  is  and  is  not  bounded: 


Polynomial  time  for  bounded  constraints:  We  can  determine  whether  any  partic¬ 
ular  response  r  is  in  A  via  testing  ultimate  satisfiability:  r  is  in  A  iff  D  is  ultimately 
satisfiable  w.r.t.  Co  for  r.  Since  Co  is  bounded,  Theorem  1  states  that  this  satis¬ 
fiability  testing  can  be  done  in  time  polynomial  in  N  and  the  Co  \ .  In  addition, 
since  Co  is  bounded,  either  there  are  only  a  small  number  of  possible  responses  (if 
Co  is  domain-bounded),  or  there  are  only  a  bounded  number  of  responses  that  are 
distinguishable  w.r.t.  the  constraints  (if  Co  is  constant-bounded,  as  discussed  in  the 
proof  of  Theorem  1)).  In  either  case,  there  are  only  a  constant  number  of  different 
responses  r  that  must  be  tested.  Thus,  by  testing  each  representative  response,  we 
can  determine  the  entire  acceptable  set  (representing  it  as  ranges  of  acceptable  val¬ 
ues)  in  time  polynomial  in  N  and  \Co\.  If  we  actually  construct  the  entire  set  A  (as 
described  in  the  theorem),  then  there  is  an  additional  polynomial  time  dependence 
on  \A\. 
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NP-hard  for  arbitrary  constraints:  For  this  case  we  show  that  computing  the 
acceptable  set  is  NP-hard  by  a  reduction  from  ultimate  satisfiability:  given  an  L- 
SEP  A  with  N  participants,  data  set  D,  constraints  CD,  and  a  possible  response  r,  A 
is  ultimately  satisfiable  for  r  iff  r  is  in  the  acceptable  set  A  for  A.  This  relationship 
follows  directly  from  the  definition  of  the  acceptable  set,  and  the  reduction  is  clearly 
polynomial  time.  Since  ultimate  satisfiability  is  NP-complete  in  N  for  arbitrary 
constraints,  computing  the  acceptable  set  must  be  NP-hard  in  N. 


A.3  Proof  of  Theorem  3 


Here  we  are  given  an  L-SEP  A,  current  state  D,  constraints  Co,  and  a  response 
r,  and  wish  to  compute  the  minimum  sufficient  explanation  E  for  rejecting  r.  This 
theorem  has  different  results  depending  on  whether  Co  consists  of  MustCon- 
straints  or PossiblyConstraint s: 


Polynomial  time  for  MustConstraints:  For  a  MustConstraint,  the  size  of  the 
minimum  sufficient  explanation  is  always  one.  We  can  compute  this  explanation  by 
adding  r  to  D  and  then  testing  each  constraint  to  see  if  it  is  unsatisfied  in  this  new 
state;  any  such  constraint  is  a  minimum  explanation.  Testing  each  constraint  on  a 
given  state  is  polynomial  in  N,  and  there  are  at  most  0(|Cx>|)  constraints,  for  total 
time  polynomial  in  N  and  Co  \ . 


NP-hard  for  Possibly  Constraints:  In  this  case  computing  a  minimum  explana¬ 
tion  is  NP-hard  in  two  different  ways.  First,  a  reduction  from  ultimate  satisfiability: 
given  an  L-SEP  A,  D,  Co,  and  r,  D  is  ultimately  satisfiable  for  r  iff  the  min¬ 
imum  explanation  for  rejecting  r  on  D  does  not  exist.  This  relationship  follows 
from  the  definition  of  an  explanation,  since  if  an  explanation  exists  it  rules  out  any 
way  of  satisfying  the  constraints,  and  the  reduction  is  clearly  polynomial.  Thus, 
since  determining  ultimately  satisfiability  is  NP-complete  in  N  (Theorem  1),  then 
computing  the  minimum  explanation  is  NP-hard  in  N. 

Second,  a  reduction  from  SET-COVER,  which  is  defined  as  follows:  We  are  given 
a  set  X  =  {1,  2, ...,  N}  and  family  of  subsets  of  F  —  {.Si,  S2, ...,  SM}  such  that 
every  Si  C  X  and  every  element  of  X  is  contained  in  some  St.  A  cover  for  this 
problem  is  a  set  F'  C  F  such  that  the  union  of  all  St  e  F'  contains  every  element 
of  X.  The  problem  is  to  determine  whether  there  exists  a  cover  of  size  J  or  smaller 
for  X. 

We  construct  the  following  L-SEP  A  with: 

•  Participants:  P  =  {p0,Pi,P2,  ■ -,Pn }■ 

•  Data  set:  D  is  a  single  table  with  one  boolean  attribute  R. 

•  Constraints:  a  set  of  PossiblyConstraint  s  CD  =  C0ACi  AC2A...  ACm 
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where 


Co  —  (Ryes  —  0) 

Ci=  f\  ( Rtme  ^  j)  for  1  <  i  <  M 

j£Si 

Ryes  =  (COUNT  (*)  WHERE  value  =  True) 

Constructing  this  L-SEP  is  clearly  polynomial  time  in  the  size  of  the  SET-COVER 
problem. 

Given  this  construction  for  A,  we  now  show  that  a  set  cover  for  X  of  size  J  exists 
iff  the  minimum  explanation  E  for  rejecting  a  response  r  of  False  for  A  with 
an  initially  empty  state  D  contains  J  +  1  constraints.  First,  given  an  explanation 
E  with  J  +  1  constraints,  a  minimum  cover  F'  is  the  set  of  all  Sl  such  that  Ci  is 
present  in  E,  for  i  f  0.  (Every  sufficient  explanation  E  contains  Co;  it  is  a  special 
case  included  just  to  handle  the  situation  where  all  participants  respond  No.  Hence, 
F'  will  be  of  size  J.)  To  see  why  this  works,  consider  an  example  set  S7  =  (3,  5}. 
This  set  is  mapped  to  the  constraint  C7  =  (7?/rue  =C  3)  A  (Rtrue  f  5).  A  sufficient 
explanation  for  rejecting  r  must  cover  every  possible  outcome  of  the  L-SEP,  and 
two  such  outcomes  are  for  either  3  or  5  participants  to  respond  True.  Thus,  if 
response  r  is  to  be  rejected,  the  explanation  E  must  cover  these  two  cases,  either 
by  choosing  C7,  or  by  choosing  some  other  constraint(s)  that  also  covers  the  cases 
of  3  or  5  True  responses.  This  follows  exactly  the  same  rules  as  a  solution  to 
SET-COVER.  Likewise,  given  a  cover  F'  for  X  of  size  J,  a  minimum  explanation 
for  rejecting  an  initial  False  response  is  the  conjunction  of  C o  together  with  all 
constraints  C7  where  S,  is  in  F',  for  a  total  size  of  J+ 1.  Thus,  any  input  to  the  SET- 
COVER  problem  can  be  reduced  to  solving  the  minimum  explanation  problem. 
Since  the  former  problem  is  NP-complete  in  the  number  of  sets  (M),  the  latter 
problem  must  also  be  NP-hard  in  number  of  constraints  (|C7>|).  Combining  this 
with  the  previous  result,  we  see  that  computing  the  minimum  sufficient  explanation 
for  Possibly  Constraints  is  NP-hard  in  N  and  NP-hard  in  C'o  \  ■ 

A.4  Proof  of  Theorem  4 

We  are  given  an  L-SEP  A  with  N  participants,  current  state  D,  constraints  C'o,  and 
a  response  r  and  wish  to  find  the  minimum  sufficient  explanation  E  for  rejecting 
r,  assuming  that  C'o  is  bounded  and  that  the  size  of  a  minimum  E  is  no  more  than 
some  constant  J .  If  Co  consists  of  MustConstraint  s,  then  we  already  know 
that  this  problem  is  polynomial  time  in  N  and  Co  from  Theorem  3. 

If  CD  is  made  up  of  PossiblyConstraint  s,  then  we  can  test  if  any  particular 
explanation  E  is  a  sufficient  explanation  via  ultimate  satisfiability:  E  is  a  sufficient 
explanation  iff  E  C  Co  and  D  is  not  ultimately  satisfiable  w.r.t.  E  for  r.  Since  the 
constraints  are  bounded.  Theorem  1  states  that  this  testing  can  be  performed  in  time 
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polynomial  in  N  and  \Cd\.  In  addition,  since  any  minimum  explanation  E  contains 
only  terms  from  Co,  restricting  E  to  at  most  size  J  means  that  the  total  number  of 
explanations  that  must  be  considered  is  polynomial  in  \C'o\.  Thus,  we  can  compute 
the  minimal  explanation  by  testing  the  sufficiency  of  every  possible  explanation  of 
size  J  or  less  and  picking  the  smallest  sufficient  explanation.  This  algorithm  runs 
in  total  time  polynomial  in  N  and  \C'n\. 

B  Proof  Sketches  for  Decision-theoretic  SEPs 

This  section  provides  proofs  regarding  the  complexity  of  computing  the  optimal 
policy  for  a  given  D-SEP  5  with  N  participants.  We  assume  that  each  participant 
will  eventually  send  an  original  response,  then  only  sends  further  messages  if  they 
receive  a  suggestion  (which  they  will  also  eventually  respond  to).  For  convenience, 
we  define  the  following  notation:  OptPolicy(<5)  is  the  problem  of  determining 
the  optimal  policy  it*  for  a  given  D-SEP  5.  OptUtility(<5,0)  is  the  problem  of 
determining  if  the  expected  total  utility  of  it*  for  5  exceeds  some  constant  6. 

B.l  Proof  of  Theorem  5  -  bounded  suggestions 

For  this  first  case,  we  assume  that  the  manager  can  send  at  most  some  constant  L 
messages  to  each  participant.  Below  we  prove  that  in  this  case  OptUtility(<5,0) 
is  PSPACE-complete,  then  use  this  result  to  prove  that  OptPolicy(<5)  is  PSPACE- 
hard. 

OptUtility(<5,0)  is  PSPACE-complete:  First,  we  show  that  OptUtility(<5,0) 
is  in  PSPACE.  Given  5,  consider  the  tree  representing  all  possible  executions,  where 
the  root  of  the  tree  is  the  initial  state  and  each  leaf  represents  a  possible  halted 
state.  From  any  state  in  the  tree,  the  next  state  may  result  either  from  the  manager 
making  a  suggestion  or  from  receiving  a  response  from  some  participant.  Hence, 
the  branching  factor  of  the  tree  is  O(N).  In  addition,  since  the  manager  may  make 
at  most  LN  suggestions  and  each  participant  may  send  up  to  L  +  1  responses,  the 
tree  is  acyclic  and  has  total  height  O(LN).  Consequently,  we  can  determine  the 
expected  utility  of  the  optimal  policy  via  a  suitable  depth-first  search  of  the  tree. 
Since  the  utility  of  a  child  node  can  be  discarded  once  the  expected  utility  of  its 
parent  is  known,  the  total  space  needed  is  just  0{LN).  Thus,  OptUtility(5,6))  is 
in  PSPACE. 

Second,  we  show  that  OptUtility(<5,6))  is  PSPACE-hard  by  a  reduction  from  QBF 
(quantified  boolean  formula).  A  QBF  problem  specifies  a  formula  p  of  the  form: 

<p  =  3x1Vy1..3xkVyk  f 

where  0  is  a  3-CNF  boolean  formula  over  the  xfs  and  yf  s.  The  computational 
problem  is  to  determine  if  p  is  true. 
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Given  p,  we  construct  a  corresponding  D-SEP  5  as  follows: 

•  Participants:  P  =  {A^  Ak,  Bll ...,  Bk},  for  a  total  of  N  =  2k  participants. 

•  States:  A  state  s  =  (ai, ak,  h, ...,  bk)  where  the  a,’s  and  bf  s  indicate  each 
participant’s  current  response  (True,  False ,  or  NoneYet).  The  a*’s  and  bi  s 
correspond  directly  to  the  ay's  and  yt’s  in  the  formula  <f.  Thus,  we  say  u<f 
is  satisfied  in  s”  if  no  a*  or  bi  has  the  value  NoneYet  and  evaluating  <f  by 
substituting  corresponding  values  for  the  xf  s  and  yfs  yields  true. 

•  Values:  V  =  {True,  False}. 

•  Actions:  A  =  (TVoOp,  Halt,  SWPttrue,  SWpjaise},  where  p  e  P. 

•  Transitions:  We  construct  T()  so  that  the  following  steps  will  occur  in  order: 

(1)  Choice:  In  the  initial  state  the  manager  may  either  perform  NoOp  (to  wait 
for  responses)  or  Halt  (if  it  has  no  winning  strategy). 

(2)  A-Turn:  A\  sends  a  False  response.  The  manager  may  choose  either  to 
execute  NoOp  (thus  accepting  a \  =  False )  or  to  suggest  a  change  to  Ai, 
in  which  case  A1  immediately  agrees  (so  a\  =  True). 

(3)  B-Turn:  The  manager  performs  NoOp,  and  receives  an  random  original 
response  (either  True  or  False)  from  B\.  Bx  refuses  any  suggestions. 

(4)  Repeat:  Repeat  A-Turn  and  B-Turn  for  (A2,  B2) ...  (Ak,  Bk),  then  Halt. 

•  Utilities:  the  only  non-zero  utilities  are  as  follows: 

U(s0,  Halt)  =  1  (quitting  f  rom  the  initial  state) 

U(s,  Halt)  =  1  +  e  if  s  ^  sq  and  <p(s)  =  True 

where  e  represents  an  infinitesimally  small,  positive  value.  Note  that  this  use  of 
e  does  not  introduce  any  serious  computational  difficulties.  The  expected  utility 
of  each  state  may  be  maintained  in  the  form  (c  +  de)  -  addition,  multiplication, 
and  comparison  (over  a  total  order)  are  easily  defined  for  such  values.  In  addi¬ 
tion,  since  e  appears  only  in  the  utility  function,  higher-order  values  such  as  e2 
do  not  arise. 

The  size  of  this  D-SEP  is  polynomial  in  N  and  the  whole  reduction  can  be  done 
in  polynomial  time.  In  particular,  while  an  explicit  representation  of  the  transition 
and  utility  functions  for  every  possible  state  would  be  exponential  in  N,  the  rules 
above  allow  all  of  the  necessary  functionality  to  be  encoded  concisely  in  terms  of 
the  current  responses.  For  instance,  the  utility  function  representing  one  possibility 
for  a  B-tum  (where  6*  changes  from  NoneY et  to  True)  is: 

T(  s  ,  NoOp,  s')  =  0.5  where 

s  =  (ai, ...,  ai,  Nonei+i, ...,  Nonek,  bi, ...,  6;_i,  Nonei,  Nonei+ 1...,  Nonek} 
s'  =  {a1,...,ai,  Nonei+i, ...,  Nonek,  bu  ...,  b^,  True,  Nonei+1, ...,  Nonek} 

Note  also  that  in  several  steps  above  we  made  statements  like  “The  manager  per¬ 
forms  action  NoOp,”  when  really  at  each  step  the  manager  has  a  choice  to  make. 
However,  since  we  can  construct  the  transition  function  in  any  desired  fashion,  we 
can  “force”  the  manager  into  any  needed  behavior  by  setting  the  transition  proba¬ 
bility  for  executing  any  other  action  to  zero.  The  same  control  over  the  probabilities 
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permits  us  to  ensure  that  participants  behave  in  certain  ways  and  that  messages  ar¬ 
rive  in  a  certain  order. 

We  now  demonstrate  an  additional  result  needed  to  complete  the  proof: 

Definition  B.l  (guaranteed  satisfying  policy)  Given  a  D-SEP  5  constructed  from 
( p  as  above,  a  guaranteed  satisfying  policy  is  a  policy  that,  if  followed  by  the  man¬ 
ager,  guarantees  that  the  SEP  will  terminate  in  a  state  that  satisfies  0.  □ 

Claim:  A  guaranteed  satisfying  policy  for  5  exists  iff  the  expected  utility  of  the 
optimal  policy  tt*  for  S  is  greater  than  1  (e.g.,  OptUtility(5,0  =  1)  is  true). 

Proof:  Clearly,  the  expected  utility  of  a  guaranteed  satisfying  policy  for  S  is  1  +  e, 
so  any  optimal  policy  must  have  utility  at  least  this  large,  which  is  greater  than  1 .  In 
the  other  direction,  by  examining  the  utility  function  we  see  that  the  only  way  for 
7 r*  to  obtain  a  utility  greater  than  1  is  for  the  SEP  to  halt  with  0  satisfied,  yielding 
reward  1  +  e.  If  this  outcome  occurs  with  any  probability  <  1  for  it*,  then  the 
total  expected  utility  will  be  less  than  1 .  Thus,  if  the  expected  utility  of  it*  is  greater 
than  1,  some  guaranteed  satisfying  policy  must  exist.  □ 

Finally,  we  show  that  the  QBF  formula  p  is  true  iff  a  guaranteed  satisfying  policy 
for  5  exists.  In  the  D-SEP,  the  manager  can  choose  whether  to  set  each  a.t  true  or 
false  by  making  a  suggestion  or  not  when  A.t  sends  its  response.  This  corresponds 
to  the  “exists”  quantifications  in  99  -  when  trying  to  prove  the  formula  true,  we  can 
choose  any  desired  value  for  Xi.  On  the  other  hand,  the  manager  cannot  influence 
the  values  of  hi  -  these  are  chosen  at  random.  Thus,  the  manager  will  have  a  guaran¬ 
teed  satisfying  policy  iff  it’s  policy  can  handle  all  possible  choices  of  the  60s.  This 
corresponds  exactly  to  the  “for  all”  quantifications  of  the  t/0s.  Note  that  we  don’t 
depend  on  the  precise  values  of  the  probabilities  -  all  that  matters  is  that  both  true 
and  false  can  occur  for  each  6*  with  some  positive  probability.  Thus,  a  guaranteed 
satisfying  policy  for  5  exists  iff  the  QBF  formula  is  true.  Since  the  latter  problem  is 
PSPACE-complete,  then  the  problem  of  determining  if  5  has  a  guaranteed  satisfy¬ 
ing  policy  is  PSPACE-hard,  and  hence  (by  the  above  claim)  OptUtility(5,6))  for 
a  bounded  number  of  suggestions  must  also  be  PSPACE-hard. 

OptPolicy(<5)  is  PSPACE-hard:  We  show  that  OptPolicy(<5)  is  PSPACE-hard 
by  reducing  from  OptUtility(<5,$).  Given  a  D-SEP  5,  we  construct  <5’  to  be  the 
same  as  5  except  that  it  has  a  new  initial  state  s'0.  From  s'(),  the  manager  may  choose 
Halt  in  order  to  end  the  process  and  gain  utility  9  +  e,  or  may  choose  NoOp,  in 
which  case  the  process  transitions  to  the  original  initial  state  .s0.  This  construction 
is  easy  to  do  and  runs  in  polynomial  time.  The  original  D-SEP  5  has  an  expected 
utility  for  n*  that  exceeds  9  iff  the  optimal  policy  for  <5’  specifies  that  the  manager 
should  perform  the  initial  action  NoOp.  This  follows  since  if  the  expected  utility 
of  5  is  9  or  less,  the  optimal  decision  is  to  Halt  immediately,  taking  the  utility 
9  +  e.  Thus,  since  OptUtility(5,6))  is  PSPACE-complete  for  a  bounded  number 
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of  suggestions,  the  corresponding  problem  of  OptPolicy(<5)  must  be  PS  PACE- 
hard. 


B.2  Proof  of  Theorem  5  -  unlimited  suggestions 


For  this  second  case,  we  assume  that  the  manager  may  make  an  unlimited 
number  of  suggestions  to  any  participant.  Below  we  prove  that  in  this  case 
Opt  Utility  (A,  (9)  is  EXPTIME-complete,  then  use  this  result  to  prove  that 
OptPolicy(<5)  is  EXPTIME-hard. 

O  P  T  U  Tl  L I T  \'  ( 8 , 0 )  is  EXPTIME-complete  :  First,  we  show  that 
OptUtility(<5,0)  is  in  EXPTIME.  Given  a  D-SEP  6,  we  can  convert  5  into 
a  Markov  Decision  Process  (MDP)  with  O(N)  possible  actions  and  one  state 
for  each  state  in  5.  The  MDP  can  be  then  solved  with  techniques  such  as  linear 
programming  that  run  in  time  polynomial  in  the  number  of  states  [35].  For  <5,  the 
number  of  states  is  exponential  in  N,  so  the  total  time  is  exponential.  Then  the 
expected  utility  of  n*  for  5  exceeds  9  iff  the  optimal  value  of  the  initial  state  of  the 
MDP  exceeds  9. 

Second,  we  show  that  OptUtility(<5,6))  is  EXPTIME-hard  by  a  reduction  from 
the  game  G4  [53].  This  game  operates  as  follows  (description  from  [34]):  The 
“board”  is  a  13-DNF  (disjunctive  normal  form)  formula  ip  with  a  set  of  assign¬ 
ments  to  its  2k  boolean  variables.  One  set  of  variables  x\, xk  belong  to  player  1 
and  the  rest  yi,  ...,yk  to  player  2.  Players  take  turns  flipping  the  assignment  of  one 
of  their  variables.  The  game  is  over  when  the  13-DNF  formula  evaluates  to  true 
with  the  winner  being  the  player  whose  move  caused  this  to  happen.  The  computa¬ 
tional  problem  is  to  determine  whether  there  is  a  winning  strategy  for  player  1  for 
a  given  formula  from  a  given  initial  assignment  of  the  variables.  Without  loss  of 
generality,  below  we  assume  that  the  original  formula  has  been  transformed  so  that 
the  corresponding  initial  assignment  sets  all  variables  to  false. 

Given  an  instance  of  the  game  G4  over  some  13-DNF  formula  ip,  we  construct  a 
corresponding  D-SEP  5  as  follows: 

•  Participants:  P  =  {A4, ...,  Akl  Bi, ...,  Bk},  for  a  total  of  N  =  2k  participants. 

•  States:  A  state  s  =  (a\,  ...,ak,b\,  ...,bk,  Pend,  Last)  where  the  afs  and 
bfs  indicate  each  participant’s  current  response  (True,  False,  or  NoneYet ), 
Pend  is  the  set  of  participants  that  the  manager  has  made  a  suggestion  to  that 
has  not  been  responded  to  yet,  and  Last  indicates  whether  the  last  message 
that  changed  a  value  was  from  some  A  or  some  B.  The  af s  and  bfs  corre¬ 
spond  directly  to  the  xfs  and  yfs  in  the  formula  ip.  Thus,  we  say  “ip  is  satisfied 
in  s”  if  no  a*  or  bi  has  the  value  NoneYet  and  evaluating  p  by  substituting 
corresponding  values  for  the  xfs  and  yfs  yields  true. 

•  Values:  V  =  {True,  False}. 
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•  Actions:  A  =  { NoOp ,  Halt ,  SWpjrUe,  SWpjaise}  where  p  e  P. 

•  Transitions:  We  construct  T()  so  that  the  following  steps  will  occur  in  order: 

(1)  Choice:  In  the  initial  state  the  manager  may  either  perform  NoOp  (to  wait 
for  responses)  or  Halt  (if  it  has  no  winning  strategy). 

(2)  Startup:  Every  participant  sends  in  a  response  False.  The  manager  then 
suggests  a  change  to  every  Bt,  who  do  not  immediately  respond. 

(3)  A-Turn:  The  manager  chooses  some  At  to  suggest  a  change  to.  A,  im¬ 
mediately  agrees,  flipping  the  current  value  of  a*.  If  p  is  now  satisfied. 
Halt. 

(4)  B-Turn:  The  manager  performs  NoOp,  and  receives  a  response  to  a  pre¬ 
vious  suggestion  from  some  random  B,,  flipping  the  value  of  l)t.  The  man¬ 
ager  immediately  sends  another  suggestion  back  to  the  same  Bt,  who  does 
not  yet  respond.  If  p  is  now  satisfied,  Halt.  Otherwise,  go  back  to  A-Turn. 

•  Utilities:  the  only  non-zero  utilities  are  as  follows: 

U(s0,  Halt )  =  1  ( quitting  f  rom  the  initial  state ) 

U(s,  Halt )  =  1  +  e  if  s  so,  s.Last  =  A,  and  p(s)  =  True 


The  size  of  this  D-SEP  is  polynomial  in  N  and  the  whole  reduction  can  be  done  in 
polynomial  time.  As  with  the  bounded  suggestions  case,  the  explicit  transition  and 
utility  functions  are  exponential  in  N,  but  the  rules  above  allow  all  of  the  necessary 
cases  to  be  represented  concisely  in  terms  of  the  current  responses,  Pend,  and 
Last.  Likewise,  we  can  “force”  the  needed  manager  and  participant  behavior  by 
appropriate  setting  of  the  transition  function. 

We  now  demonstrate  an  additional  result  needed  to  complete  the  proof: 

Definition  B.2  (guaranteed  A-Win  policy)  Given  a  D-SEP  5  constructed  from  p 
as  above,  a  guaranteed  A-Win  policy  is  a  policy  that,  if  followed  by  the  manager, 
guarantees  that  the  SEP  will  terminate  in  a  state  that  satisfies  p  and  where  the  last 
step  was  an  “A-Tum.”  □ 

Claim:  A  guaranteed  A-Win  policy  for  5  exists  iff  the  expected  utility  of  the  opti¬ 
mal  policy  Ti*  for  5  is  greater  than  1  (e.g.,  OptUtility(<5,0  =  1)  is  true). 

Proof:  Analogous  to  the  claim  previously  given  for  a  guaranteed  satisfying  policy 
in  the  bounded  suggestions  case.D 

Finally,  we  show  that  a  winning  strategy  exists  for  player  1  in  6'4  iff  a  guaranteed 
A-Win  policy  exist  for  5.  We  consider  the  possible  actions  for  the  SEP  manager, 
who  represents  player  1 .  In  the  initial  “Choice”  step,  if  the  manager  does  not  have 
a  guaranteed  A-Win  policy,  it  is  best  to  Halt  immediately  and  settle  for  a  utility  of 
1.  If  the  manager  decides  to  play,  then  it  also  has  a  choice  in  Step  3  of  which  At 
to  suggest  a  change  to  -  this  corresponds  to  choosing  which  Xi  for  Player  1  to  flip. 
Step  4  corresponds  to  Player  2’s  flip  of  some  y,,  and  the  manager  has  no  choice 
to  make.  Thus,  given  a  winning  strategy  for  Player  1  in  G4,  it  is  easy  to  construct 
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a  guaranteed  A- Win  policy  for  5  (mapping  xt  flips  to  Ai  change  suggestions),  and 
vice  versa.  Since  the  problem  of  determining  if  Player  1  has  such  a  winning  strat¬ 
egy  for  G4  is  EXPTIME-hard,  the  problem  of  determining  if  5  has  a  guaranteed 
A- Win  policy  is  EXPTIME-hard,  and  hence  (by  the  above  claim)  the  problem  of 
OptUtility(<5,60  must  also  be  EXPTIME-hard. 

OPTPoLiCY((5)is  EXPTIME-hard:  This  proof  follows  exactly  the  same  form 
as  the  proof  of  OptPolicy(<5)  for  the  bounded  suggestions  case.  Since 
OptUtility(<5,0)  is  EXPTIME-complete  for  an  unlimited  number  of  suggestions, 
the  corresponding  problem  of  OptPolicy(<5)  must  be  EXPTIME-hard. 


B.3  Proof  of  Theorem  6 


Here  we  show  how  to  compute  the  optimal  policy  it*  in  time  polynomial  in  N, 
assuming  a  K-partitionable  utility  function  and  that  the  manager  sends  at  most  one 
suggestion  to  any  participant.  Although  the  formalisms  are  very  different,  the  key 
observation  underlying  this  proof  is  similar  to  that  of  Theorem  1.  Here  we  also 
create  a  state  space  that  only  models  the  number  of  participants  in  each  group, 
rather  than  their  specific  members. 

We  define  a  summary  state  function  S  =  {C,  D,  E}  where 

•  C  =  (C\, ...,  Ck)  where  Cr  is  the  number  of  responses  Vt  that  were  received 
that  do  not  have  a  suggestion  pending. 

•  D  =  ( I) | , ...,  Dk)  where  Dt  is  the  number  of  responses  V)  that  were  received 
that  do  have  a  suggestion  pending. 

•  E  =  (Ei, ...,  Ek)  where  E,  is  the  number  of  responses  V,  that  were  received 
as  a  response  to  a  suggestion. 

In  what  follows,  the  notation  C  —  v  indicates  “subtract  one  from  the  variable  in  C 
specified  by  value  vT  Given  S,  we  can  define  the  following  transitions  (omitting 
details  for  states  where  everyone  has  already  responded): 

T({C,D,E},SWV,  {C-v,D+v,E  })  =  1 

T({C,  D,  E},  NoOp,{C+v,D,  E  })  =  Po(C,  D,  E)-pv 

T({C,  D,  E},  NoOp,{C,  D-v,E+w })  =  psv(C,  D,  E)-pvw 

The  first  equation  represents  the  manager  requesting  that  some  respondent  switch 
their  response  from  the  value  v;  the  state  is  updated  to  note  that  a  suggestion  has 
been  made  (with  probability  1).  The  next  two  equations  handle  the  uncertainty 
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when  the  manager  decides  to  wait  for  the  next  message  to  arrive.  Specifically,  the 
second  equation  handles  the  case  when  the  next  message  is  an  original  response 
from  a  previously  unheard  from  participant  (probability  p0(C,  D,  E )),  while  the 
third  equation  handles  the  case  where  the  next  message  is  a  response  to  a  previously 
made  suggestion  to  switch  from  value  v  (probability  psv(C,  D,  E )). 

At  any  time  each  participant’s  response  is  either  counted  once  among  the  K  vari¬ 
ables  of  each  of  C,  D,  or  E,  or  has  not  yet  been  received.  The  number  of  possible 
states  is  thus  the  number  of  ways  of  dividing  N  participants  among  3 K  +  1  groups, 
which  is: 


\S\ 


f  N  +  3K\ 

l  3A'  ) 


0{N3K ) 


Because  of  the  restriction  to  send  at  most  one  suggestion  to  each  participant,  the 
graph  formed  by  the  transition  function  over  these  states  is  acyclic.  Thus,  the  op¬ 
timal  policy  may  be  computed  via  a  depth-first  search  over  the  graph  in  total  time 

0(N3K). 
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